Certified Platform Administrator

Regla de respuesta automática: Web-to-Case permite reglas de respuesta automática. Crea una entrada con criterio Subject contiene “forgot” Y “password” y envía el correo automáticamente.

Plantilla de correo electrónico: Define el contenido con las instrucciones de restablecimiento y asígnalo a la entrada de la regla.

Email-to-Case: Sirve para crear casos desde emails, no para responder automáticamente a formularios Web-to-Case.

Plantilla de restablecimiento de contraseña: Se usa en el proceso de restablecimiento de contraseña del usuario de Salesforce, no para correos basados en casos según el asunto.

Las acciones que se muestran en la app móvil provienen de la sección Salesforce Mobile and Lightning Experience Actions del page layout del objeto. Añade la acción en esa sección del layout de Account para que aparezca en móvil.

B El compact layout controla campos, no acciones.

C El Mobile Navigation gestiona pestañas/menú, no acciones del registro.

D Una Lightning App no determina qué acciones aparecen en las páginas de registro móviles.

Use a record-triggered Flow on Opportunity (after save). When Stage = Closed Won, the flow can query related Opportunities with the same AccountId that are still open and update them to Closed Lost.

B Outbound Message: sends data externally; doesn’t update related records.

C Workflow Rule: can’t update multiple related records; also retired in favor of Flow.

D Quick Action: requires a user click, not automatic.

Data Loader es un cliente de API, por lo que al exigir MFA para logins por API Salesforce inicia el flujo de alta y verificación de MFA. En el primer acceso, el sistema pide instalar una app de autenticación y vincularla con la cuenta de Salesforce.

B: El security token es para logins por usuario-contraseña desde IPs no confiables; no es el aviso de MFA ni cumple MFA.

C: Los códigos por email/SMS no son un método admitido de MFA en Salesforce; se requiere una app de autenticación u otro factor aprobado.

Se deben usar las Rangos de IP de inicio de sesión en el perfil para bloquear el acceso desde IPs externas. Los Trusted IP Ranges a nivel de organización no bloquean; solo evitan el código de verificación.

B: Correcto. Define los rangos de IP en cada perfil que quieras restringir.

C: Correcto. Al marcar Enforce Login IP Ranges on Every Request, el sistema valida la IP durante toda la sesión (no solo al inicio), y corta el acceso si cambia la IP.

A: Asignar SSO no controla el acceso por red/IP.

D: Las llaves U2F son un método de MFA, no aplican para restricciones por IP u horarios.

Los paneles muestran una instantánea del último refresh; si los datos cambiaron desde entonces, el informe (que se ejecuta en vivo) mostrará valores distintos (A). Además, el panel puede ejecutarse “como un usuario específico”; al entrar al informe, éste se ejecuta con los permisos del visor, por lo que las cifras pueden variar (C).
B es incorrecta: el informe ya muestra datos en tiempo real.
D impediría ver el informe, no mostrar valores distintos.

Solo Flow Builder permite eliminar registros de forma automática en Salesforce; configura un flow disparado por registro o programado con el elemento Delete Records y los criterios necesarios.

Process Builder y Workflow no pueden eliminar registros.

Automation Studio pertenece a Marketing Cloud y no sirve para automatización de registros en el core de Salesforce.

Solo los muting permission sets pueden restar permisos otorgados por un permission set group. Crea uno, selecciona Delete en los objetos correspondientes y asígnalo al grupo.

A: Los roles manejan acceso a registros (sharing), no permisos de objeto (CRUD).

B: El perfil puede quitar Delete, pero el grupo de conjuntos de permisos lo volverá a otorgar (la suma es acumulativa).

D: Un permission set solo otorga permisos; no los quita.

Usa la Visibilidad Dinámica de Componentes en Lightning App Builder. Con filtros (p. ej., User.Profile, campos del registro, Form Factor) los componentes se muestran solo a quien corresponde según rol/perfil/condición, manteniendo la página relevante y limpia. Eliminar componentes o campos (A/B) puede quitar información necesaria; añadir más pestañas (D) incrementa la complejidad sin personalizar por rol.

Cree una fórmula entre objetos en Opportunity (tipo de retorno: Texto) que referencie Account.Industry. Así se muestra el valor del Account en la Opportunity, es de solo lectura y se actualiza automáticamente si cambia el Industry de la cuenta.

B/C: Agregan campos en Account, no resuelven mostrar el dato en Opportunity.

D: Opportunity ya tiene un lookup estándar a Account; no se necesita (ni procede) una relación maestro-detalle para este requerimiento.

El branding móvil se configura en Setup → Mobile Apps → Salesforce → Branding (o en Themes and Branding). Se puede definir un color de marca que controla el color del encabezado/la barra de navegación de la app y cargar un logo para la pantalla de carga (splash). No se admite cambiar el color de fondo de los registros ni el color de encabezados de pop-ups.

A/B: Una relación muchos-a-muchos se implementa con un objeto de unión que tiene dos relaciones maestro-detalle, una hacia cada objeto a relacionar. Así un registro de un objeto puede relacionarse con muchos del otro y viceversa, además de habilitar roll-ups.
C: Dos lookups no proporcionan el comportamiento de maestro-detalle ni los roll-ups; no es el patrón estándar.
D: Los campos URL no aportan a la relación.

Flow Builder (Screen Flows) permite construir asistentes guiados con pantallas, campos y lógica para que el usuario capture datos.

Process Builder: Sin interfaz de usuario; se ejecuta en segundo plano.

Outbound Message: Envía mensajes a sistemas externos; no muestra formularios.

Approval Process: Sirve para enviar registros a aprobación; no crea wizards de entrada de datos.

Usa la Visibilidad Dinámica del Componente en Lightning App Builder. Agrega dos filtros:
• User.Profile.Name = Sales User para limitar por perfil.
• Form Factor = Phone para mostrarlo solo en móviles.
El Rol (B) no cumple el requisito de perfil, y View = Mobile/Tablet (D) no es un filtro válido; el filtro soportado para dispositivo es Form Factor.

Con OWD = Privado y la necesidad de conceder acceso según valores del registro (Tipo de Oportunidad = Cross-sell) sin importar el propietario, lo más adecuado es una regla de compartición por criterios que comparta esas oportunidades a un grupo público con los expertos.
A. Cambiar el OWD a Público abriría todas las oportunidades a todos—demasiado permisivo.
B. Las reglas por propietario dependen del dueño del registro, no del Tipo; no seleccionan todas las cross-sell.
C. Territory Management + compartición manual es más complejo y de mayor mantenimiento que una única regla por criterios.

Big Deal Alerts es una función estándar que envía correos a destinatarios definidos cuando una oportunidad cumple criterios como Monto, Probabilidad y ventana de Fecha de Cierre. Puede crearse una regla “Monto ≥ $500,000” y, si se desea, añadir filtros por probabilidad o periodo; es rápido de configurar y no requiere automatización personalizada.

A. Recordatorios de actualización: Solo recuerdan a los dueños que actualicen sus oportunidades; no disparan alertas por umbral.

B. Advertencias en Kanban: Son indicadores visuales; no envían correos a directivos.

D. Componente Key Deals: Muestra oportunidades clave en la UI, pero no genera notificaciones.

Usa un usuario de ejecución estático con acceso a todas las Oportunidades (p. ej., Sys Admin o ejecutivo con “View All”). Los tableros evalúan los datos según el usuario que ejecuta; así todos verán los resultados agregados aunque no tengan acceso a cada registro, sin modificar el sharing.
A. Compartir la carpeta no aumenta la visibilidad de registros.
C. Varios tableros por perfil son innecesarios y difíciles de mantener.
D. Los filtros no otorgan acceso; los usuarios seguirán limitados a sus propios registros.

La Mass Transfer Tool (Configuración → Data → Mass Transfer Records) permite transferir en masa la propiedad de Cuentas y Oportunidades. Al transferir Cuentas puedes incluir sus Oportunidades y marcar opciones para conservar el Account Team y el Opportunity Team, cumpliendo el requisito.

A/B. Data Loader / Dataloader.io: Se puede actualizar el OwnerId, pero es más complejo y no ofrece la casilla de “conservar equipos”.

D. Data Import Wizard: No está pensado para cambios masivos de propietarios de Oportunidades y no conserva equipos.

Con Account Teams y un Equipo de Cuenta Predeterminado, se define un conjunto reutilizable de usuarios (gerente, ingeniero, asistente) con sus roles y nivel de acceso, que se añade con un clic o se añade automáticamente a cada cuenta del propietario. Como la composición del equipo siempre es la misma, esta es la opción más eficiente y fiable.

B. Colas: No se usan para Cuentas (sirven para Leads, Cases, etc.), por lo que no resuelven la colaboración sobre registros de Cuenta.

C. Opportunity Teams: Aplican a oportunidades y a los splits de ingresos; no otorgan colaboración directa sobre la Cuenta.

D. Compartir manualmente: Funciona pero es lento y propenso a errores comparado con los equipos de cuenta predeterminados.

Marcar el campo como Requerido a nivel de campo (“Make this field required”). Un campo universalmente requerido se valida en todos los puntos de entrada—interfaz, API, importaciones e integraciones—asegurando que cada Invoice tenga valor en Billing System.

A. Los tipos de registro no vuelven un campo obligatorio; eso se hace en el page layout y no se aplica a la API.

C. Process Builder/Flow es innecesario y no garantiza al 100% el valor.

D. Un proceso de aprobación no obliga a capturar el dato.

El administrador debe reproducir el problema en el contexto del usuario. Con “Iniciar sesión como” (tras habilitar Administrators Can Log in as Any User o con acceso concedido por el usuario) verá el mismo perfil, permission sets, acceso a registros, layout, reglas de validación y flows que experimenta el VP. Solo así se detectan problemas que no aparecen con permisos de Sys Admin.
A: No hace falta—las herramientas nativas bastan.
C: Nunca se debe solicitar la contraseña del usuario (política de seguridad).
D: Entrar como Sys Admin no reproduce problemas de permisos/validación propios del VP.

En la conversión de leads, Salesforce permite copiar valores de campos del Lead a Cuenta, Contacto y Oportunidad mediante el mapeo de campos del Lead. Para llevar “Product Category” a la Oportunidad:

1. Crear el campo destino en Oportunidad (mismo o compatible tipo de dato).

2. Ir a Setup → Object Manager → Lead → Fields & Relationships → Map Lead Fields y mapear el campo de Lead con el de Oportunidad.
Así el valor se transfiere automáticamente al convertir, sin automatización adicional.

A. Workflow: No es necesario y es poco fiable; el mapeo nativo ya resuelve el requerimiento.

C/D. El objeto Producto no participa en el mapeo de conversión; solo se puede mapear a

B. Texto enriquecido: El componente Rich Text permite mostrar un mensaje y, con Component Visibility, filtrarlo por condiciones (p. ej., Tipo de registro = Crítico) y mostrarlo en negrita.
D. Registro relacionado: Con el componente Related Record del objeto Cuenta (padre) se pueden editar campos de la Cuenta (como Estado) directamente desde la página del Caso.
A. Detalle del registro: Solo muestra los campos del Caso; no sirve para mensajes condicionales ni para editar la Cuenta.
C. Lista relacionada: Muestra registros hijos; no permite editar rápidamente los campos de la Cuenta (padre).

El campo estándar Expected Revenue se calcula automáticamente como Amount × Probability. La Probability proviene del valor configurado en la etapa. Si el Expected Revenue está mal, hay que actualizar las probabilidades de las etapas (Setup → Object Manager → Opportunity → Fields & Relationships → Stage → Probability).
A. No existe un “ingreso esperado por etapa”; el valor se calcula por registro.
C. No hay un “valor de closed won” que afecte esta fórmula.
D. La categoría de pronóstico no interviene en el cálculo de Expected Revenue.

Salesforce dispone de la función nativa de Tareas Recurrentes. Para que los usuarios creen tareas con repetición (p. ej., cada 2 semanas), el administrador debe habilitarla en Setup → Activity Settings → Enable Creation of Recurring Tasks. Al activarse, aparece la opción de repetición en la creación de Tareas.

A. Regla de flujo de trabajo: No puede programar repeticiones reales; solo se ejecuta ante cambios y no soporta periodicidad quincenal directa.
B. Activar Actividades Recurrentes: Es una configuración antigua asociada a eventos recurrentes; no habilita la interfaz de tareas recurrentes.
C. Flow para crear tareas recurrentes: Se podría, pero no hace falta y sería más complejo; ya existe la funcionalidad estándar.

A. Configurar un flujo programado en Flow Builder: Correcto. Un Flow desencadenado por programación puede ejecutarse semanalmente, recorrer Cuentas, contar los Casos abiertos (Status != Closed) y actualizar un campo en la Cuenta. Es la forma nativa de ejecutar lógica por lotes en un calendario.
B. Proceso programado en Process Builder: Process Builder solo maneja acciones en base a tiempo por registro, no programaciones recurrentes para todos los registros como “semanal.”
C. Proceso al editar: Solo se dispara cuando se edita la cuenta; no recalcula de forma semanal si no hay cambios.
D. Workflow con mensaje saliente: Envía datos a un sistema externo; no sirve para conteos y actualizaciones semanales dentro de Salesforce.

C. Usar Depurar en Flow Builder: Es la mejor opción. Permite ejecutar el flow en modo de prueba, pasar variables de entrada, ver la ruta exacta que sigue y los valores de variables/errores paso a paso, aunque el flow se dispare desde Process Builder.
A. Audit Trail: Solo muestra quién cambió la configuración; no ayuda a seguir la lógica del flow.
B. Debug logs: Viable pero menos directo; hay que capturar el log y revisar entradas genéricas de “Workflow/Flow”. El depurador del Flow es más claro y específico.
D. Registros de correo: Solo aplican a problemas de envío de emails; no sirven para depurar lógica de flows.

B. Enviar notificaciones por correo: Las acciones de escalación pueden notificar a usuarios, roles o colas por email cuando se cumple el tiempo.
C. Reasignar el Caso: La acción de escalación puede reasignar el caso automáticamente a otro usuario o a una cola.
A. Cambiar la prioridad: Las reglas de escalación no actualizan campos; para ello se usaría Flow/Process u otra automatización.
D. Reabrir el caso: Las reglas de escalación no cambian el estado para reabrir un caso cerrado.

C. Diseño compacto personalizado: En Lightning, el Panel de Destacados muestra los campos definidos en el Compact Layout del objeto. Para que el campo se muestre, crea (o edita) un diseño compacto de Cuenta, incluye el campo y asigna ese diseño compacto como Principal.

A. Obligatorio + arriba: Afecta solo al formulario del detalle, no al panel de destacados.

B. Arrastrar desde el page layout: El panel no se configura en el page layout; depende del diseño compacto.

D. Nuevo layout/sección: Las secciones controlan solo la página de detalle; no el panel de destacados.

Los procesos de aprobación admiten un conjunto específico de acciones nativas en Envío inicial, Aprobación final, Rechazo final y Retiro. Las acciones admitidas son Actualización de campo, Alerta por correo, Tarea y Mensaje saliente (Outbound Message).

A. Actualización de campo: Válida. Permite actualizar automáticamente campos del registro (p. ej., poner Estado = “Aprobado” o grabar la fecha de aprobación).

B. Alerta por correo electrónico: Válida. Envía correos con plantillas a solicitantes, jefes u otros interesados cuando se envía/aprueba/rechaza la solicitud.

C. Flujo autolanzado: No está disponible directamente como acción del proceso de aprobación. Si necesitas ejecutar un Flow, hazlo con Flow/Process Builder que reaccione a un cambio de estado provocado por la aprobación, o mediante Apex.

D. Publicación en Chatter: No es una acción nativa del proceso de aprobación. Publicar en Chatter se realiza con Process Builder/Flow u otra automatización personalizada, no desde las acciones del proceso de aprobación.

Usa Sales Path (Path Key Fields) en la Oportunidad. Path permite definir Campos Clave y Guía para el Éxito por etapa, resaltando lo más importante a medida que la oportunidad avanza.
A: Sales/Opportunity Process solo controla qué etapas están disponibles.
C: Workflow Rules automatiza acciones; no muestra campos en la interfaz.
D: Dynamic Forms puede mostrar/ocultar secciones por condiciones, pero Path está diseñado específicamente para la guía y campos por etapa en Oportunidades.

D. Habilitar el seguimiento en el feed para Tableros permite la opción Publicar en Chatter y así compartir componentes del tablero en Chatter.
A. “Ver tablero como” (tableros dinámicos) solo controla el usuario de ejecución/visibilidad.
B. “Descargar gráfico” guarda una imagen; no comparte en Chatter.
C. Los snapshots de reportes capturan datos programados; no se relacionan con compartir en Chatter.

A. Actualizar el diseño de página: Si el campo no está colocado en el layout asignado al perfil/tipo de registro del usuario, no se mostrará.
D. Revisar la seguridad a nivel de campo: Si el FLS está en Oculto o Solo lectura para ese perfil o no se otorgó mediante un permission set, el campo no estará disponible.
B. Actualizar OWD: Los OWD controlan acceso a registros, no la visibilidad de campos; no hacen aparecer el campo.
C. Audit Trail: Sirve para ver cambios de configuración, pero no resuelve directamente problemas de visibilidad del campo.

A. Informe estándar de Campañas con “Value Won Opportunities in Campaign”: Correcto. Las campañas incluyen estadísticas estándar de resumen (p. ej., Número/Valor de Oportunidades Ganadas). Un informe de Campañas muestra ese ingreso por campaña sin automatización adicional.
B. Trabajos de datos periódicos: Innecesario; los valores de resumen de Campaña se calculan automáticamente.
C. Campo personalizado + workflow: No hace falta y es frágil; un workflow no mantiene de forma fiable agregados entre oportunidades relacionadas.
D. Roll-up de Oportunidad→Campaña: No es posible porque la relación es de búsqueda (Primary Campaign Source); los roll-ups requieren master-detail.

B. Security Health Check: Revisa la configuración de seguridad del org (incluidas opciones de sesión como tiempo de inactividad, restricciones de IP, protección contra clickjacking), puntúa el estado y permite corregir valores de riesgo.
A. Seguimiento del historial de campos: Solo registra cambios en datos; no evalúa seguridad ni sesiones.
C. Registro de auditoría de Setup: Muestra cambios de configuración; no detecta ni corrige vulnerabilidades.
D. Predeterminados de toda la organización: Controlan acceso a registros; no están orientados a seguridad de sesión.

B. El flujo está inactivo: Si no hay una versión Activa en Producción, el flujo no se ejecuta (los flows disparados por registros no se lanzan; los autolaunched/screen tampoco), y no se crean registros.
A. “Solo lectura” no es un estado que evite la ejecución de un flow.
C. No existe un concepto de “URL desactivada” que explique esto.
D. Las condiciones de inicio se configuran dentro del flow; el problema típico en producción es que el flow no está activado.

C. Flow Solutions: Flujos y plantillas preconstruidas en AppExchange que se instalan y adaptan rápido. Encajan con un proceso plantillado como una calculadora hipotecaria que cree leads, y muchas opciones son gratuitas—ideal para poco tiempo y sin presupuesto.
A. Lightning Community: Hace referencia a sitios de Experience Cloud; no aporta por sí solo una calculadora ni un proceso de generación de leads.
B. Bolt Solutions: Plantillas preconfiguradas de Experience Cloud (portales); no resuelven una calculadora/flujo interno.
D. Lightning Data: Paquetes de enriquecimiento de datos (de pago); no sirven para construir la calculadora ni el proceso y además añadirían coste.

B. Se eliminará cualquier vista de lista basada en ese campo: Al cambiar el tipo de dato, las vistas con filtros sobre ese campo pueden quedar inválidas y borrarse.
D. Las reglas de asignación y escalación pueden verse afectadas: Las reglas que usan el campo pueden dejar de funcionar o comportarse distinto tras el cambio (operadores y valores de texto vs. picklist), por lo que hay que revisarlas.
A. No habrá pérdida de datos con un conjunto global: Incorrecto; al convertir de Texto a Picklist solo se conservan valores que coincidan exactamente con las opciones permitidas—otros pueden quedar inválidos/vacíos aunque uses un conjunto global.
C. Actualizaciones automáticas de Visualforce: Incorrecto; Salesforce no actualiza automáticamente VF ni otras referencias personalizadas—hay que ajustarlas manualmente.

A. Editar el tipo de informe de Event y añadir campos por lookup: Correcto. En un tipo de informe personalizado se puede usar “Add fields related via lookup” para exponer campos del Contacto padre en el informe de Event.
B. Campos fórmula en Event: No es necesario y duplica datos; el informe puede acceder a los campos del padre mediante el tipo de informe.
C. Nuevo tipo de informe con Event como primario y Contact como relacionado: El “with” aplica a objetos hijo; aquí Contact es el padre de Event. Lo correcto es añadir los campos por lookup.
D. Dashboard con filtros: Los tableros solo visualizan lo que trae el informe; no agregan campos entre objetos.

Usa una dependencia de campos para que Product Category sea la lista controladora y Lead Source sea la lista dependiente, mostrando solo los valores válidos para la categoría seleccionada.

A. Los tipos de registro podrían limitar valores, pero obligan a elegir un tipo de registro en lugar de basarse en el valor del campo Product Category; el requisito pide dependencia directa del campo.
C. Los procesos de negocio en Leads solo afectan a Lead Status, no a Lead Source; no resuelven el problema.
D. Los diseños de página no filtran valores de picklist en función de otro campo; solo controlan disposición y obligatoriedad.

Las Reglas de Escalación permiten evaluar de forma automática el tiempo abierto del caso, reasignarlo a una cola y enviar notificaciones cuando se supera un umbral.

A. Reglas de Escalación: Automatización basada en tiempo que puede mover casos a una cola urgente y avisar al manager.
B. Reglas de Asignación: Solo aplican al crear el caso; no reasignan tras un retraso.
C. Informes Programados: Aportan visibilidad, pero no ejecutan acciones.
D. Actualizaciones de Tableros: Solo visualización; no hay automatización ni alertas.

El Proceso de Soporte define qué valores de estado de caso están disponibles para un tipo de registro específico. Si “Closed” no está incluido en ese proceso, los usuarios no lo verán como opción.

A. El tipo de registro controla valores de lista, pero en casos lo que realmente manda es el proceso de soporte.

C. El diseño “Close Case” solo se usa para capturar información al cerrar, no habilita el estado.

D. Esa casilla afecta reportes y visibilidad, pero no la disponibilidad de la opción “Closed”.

El permiso Manage Cases permite transferir la propiedad de los casos.

Los Administradores del Sistema tienen permisos completos, incluyendo la reasignación de casos.

Un rol jerárquico superior no garantiza la capacidad de transferir propiedad si no hay reglas de uso compartido.

El permiso de solo lectura en la cuenta no permite cambiar la propiedad de los casos.

Las reglas de compartición basadas en criterios permiten compartir automáticamente registros que cumplan condiciones específicas con otros roles o equipos.

Como ambos equipos están en niveles paralelos dentro de la jerarquía, el acceso jerárquico no los conecta entre sí.

La compartición manual no es práctica en escenarios de muchos registros.

El uso compartido por propietario solo amplía acceso hacia arriba en la jerarquía, no entre equipos pares.

Las reglas de respuesta automática (auto-response rules) son las que permiten enviar correos de confirmación diferentes según criterios como la prioridad del caso.

Lo correcto es crear una sola regla de respuesta automática con tres entradas de criterio, una para cada nivel de prioridad (Baja, Media, Alta).

Las reglas de flujo de trabajo no permiten gestionar varias plantillas de esta manera.

Las reglas de asignación solo definen a qué usuario o cola se asigna el caso, no las notificaciones.

La opción C no es la más eficiente: aunque funcionaría, la mejor práctica es una regla con varias entradas.

Un Grupo de Difusión de Chatter (Broadcast Group) permite que solo los propietarios y administradores del grupo publiquen actualizaciones, mientras que el resto de miembros únicamente pueden comentar.

Es la mejor opción porque el comité puede compartir información oficial y los demás empleados pueden interactuar sin generar publicaciones nuevas.

Grupo No Listado solo controla la visibilidad, no las publicaciones.

Recomendaciones de Chatter sugiere contactos o contenido, no gestiona permisos de publicación.

Stream de Chatter simplemente agrega feeds, no restringe quién publica.

Las Reglas de Escalación permiten reasignar automáticamente un caso o notificar a los responsables cuando cumple con ciertas condiciones, como estar abierto más de 7 días.

Reglas de Respuesta Automática solo envían correos electrónicos de respuesta, no cambian propietarios.

Reglas de Asignación se ejecutan al crear el caso, no después de varios días.

Reglas de Validación bloquean datos incorrectos, pero no gestionan la propiedad de casos.

La Puntuación de oportunidades de Einstein analiza datos históricos para asignar una puntuación de probabilidad de cierre y mostrar factores clave. Así, los reps pueden ordenar listas/Kanban por puntuación y priorizar los deals con mayor probabilidad de ganarse.
A: Captura de actividad registra correos/eventos; no prioriza oportunidades.
C: Personalización de búsqueda solo ajusta resultados de búsqueda.
D: Puntuación de leads aplica a Leads, no a Oportunidades.

En un Screen Flow la visibilidad se gestiona con Component Visibility del componente de pantalla. Crea el picklist “Specific Search Engine” y configúralo para que solo se muestre cuando LeadSource = “Search Engine”. Márcalo como Required para que se exija solo cuando esté visible.

B: Las reglas de validación no muestran/ocultan campos en la pantalla; solo validan al guardar.

C: Los elementos de asignación asignan valores; no controlan visibilidad.

D: “Filtro condicional en el elemento de pantalla” no es el mecanismo correcto para mostrar/ocultar; los filtros condicionan colecciones/opciones, no la visibilidad del componente.

Para mostrar una lista relacionada de Shipments en la Cuenta, Shipments debe ser el hijo con un Lookup a Account.

La condición de que los envíos permanezcan al borrar la Cuenta descarta Maestro-Detalle (los hijos se eliminan con el maestro).

A: No es posible/adecuado; un objeto estándar como Account no puede ser detalle en maestro-detalle.

C: Dirección invertida; un lookup desde Cuenta a Shipments no crea la lista relacionada de múltiples Shipments en la Cuenta.

AppExchange ofrece muchos paquetes de tableros preconstruidos, a menudo gratuitos, que se instalan rápido y se personalizan ligeramente. Esto permite cumplir la fecha límite sin gasto adicional. Capacitar (A) lleva tiempo, crearlos desde cero (B) arriesga la entrega, y contratar un consultor (D) aumenta el presupuesto.

B: Los objetos estándar (por ejemplo, Cuenta, Contacto, Oportunidad) vienen de fábrica con Salesforce.
C: Tanto los objetos estándar como los personalizados incluyen campos estándar como Fecha de creación, Última modificación, Propietario, etc.
A: Las relaciones maestro-detalle no se limitan a objetos estándar; el detalle debe ser un objeto personalizado.
D: No se pueden crear nuevos objetos estándar; se crean objetos personalizados.

Los Permission Sets son la forma recomendada de otorgar permisos adicionales a un grupo de usuarios sin tener que modificar sus perfiles.

Un Rol (A) solo controla la visibilidad de registros en la jerarquía, no da acceso a objetos.

El Manual Sharing (B) se usa para registros individuales, no para acceso global al objeto.

Crear un nuevo perfil (D) sería innecesario y poco eficiente. Salesforce recomienda: perfil = acceso base y permission sets = permisos adicionales específicos.

Cuando se crea un caso manualmente en Salesforce, aparece una casilla llamada “Assign using active assignment rules”. Si está seleccionada, Salesforce aplicará las reglas de asignación activas, incluso para casos manuales.

En este escenario, la regla de asignación del administrador está enviando los casos a la Cola de Casos Automatizados, por eso los casos manuales terminan con el propietario incorrecto.

Opción A es incorrecta porque las reglas de asignación no se aplican en paralelo; solo se ejecuta un conjunto de reglas.

Opción C no aplica, ya que el problema no es un campo faltante.

Opción D es incorrecta porque las reglas de escalamiento no reasignan propiedad al crear casos, solo actúan después de que el caso lleva demasiado tiempo abierto.

Las Reglas de Asignación de Casos permiten asignar automáticamente los casos nuevos a una cola o a un usuario en función de criterios como campos de la cuenta, el origen del caso o campos personalizados.

En este escenario:

Casos de cuentas Silver/Gold → Cola de Soporte Regular

Casos de cuentas Platinum → Cola de Soporte Prioritario

Esto es precisamente lo que permiten las Reglas de Asignación.

Reglas de Workflow sirven para actualizar campos o enviar notificaciones, no para asignar casos a colas.

Reglas de Casos no existen como funcionalidad; es un distractor.

Reglas de Escalamiento se usan cuando un caso permanece abierto demasiado tiempo, no para la asignación inicial.

Cuando una organización implementa My Domain, Salesforce recomienda que todos los usuarios accedan mediante la URL personalizada (ejemplo: https://nto.my.salesforce.com). Sin embargo, durante el periodo de transición, es común que los usuarios sigan usando https://login.salesforce.com.

Para permitir un periodo de gracia y al mismo tiempo guiar a los usuarios a actualizar sus marcadores, el administrador debe configurar la Política de Redirección como Redirigir con advertencia. De este modo:

Los usuarios que intenten iniciar sesión con la URL antigua serán redirigidos automáticamente al dominio personalizado.

Además, verán una advertencia que les recuerda actualizar sus marcadores.

Opción A no ayuda, ya que no redirige a los usuarios.

Opción B y C bloquean el acceso desde la URL antigua sin dar un periodo de gracia.

Opción D es la correcta porque ofrece redirección más advertencia = periodo de transición.

Cuando los usuarios de Salesforce necesitan acceder a datos almacenados en un sistema externo, la mejor práctica es usar Objetos Externos mediante Salesforce Connect. Los objetos externos reflejan datos que residen fuera de Salesforce (como información de envíos), y el administrador puede mostrarlos en la interfaz añadiendo una pestaña personalizada.
De esta forma, los agentes de soporte pueden consultar los registros de envíos directamente desde Salesforce sin necesidad de duplicar o importar los datos.

Opción A no aplica; las vistas divididas sirven para navegar registros, no para integrar sistemas externos.

Opción C solo da control sobre vistas de lista, pero no permite acceder a datos externos.

Opción D asume que los registros de envíos existen dentro de Salesforce, lo cual no ocurre en este caso.

Un Filtro de panel permite a los usuarios filtrar dinámicamente los datos en el panel por campos específicos como origen del caso, estado o propietario, sin necesidad de crear múltiples paneles.

Bucket Column se usa en informes para agrupar valores en categorías, no para filtrar paneles.

Componente de panel es solo una visualización (gráfico, tabla, métrica), no un filtro.

Gráfico combinado es un tipo de gráfico, no una opción de filtrado.

Por lo tanto, la forma correcta de permitir a los agentes profundizar en el panel por origen, estado o propietario es añadir un Filtro de panel.

Cuando se crea una acción programada en Process Builder (o en Flujos con rutas programadas), esta se agenda para ejecutarse solo si los criterios siguen siendo verdaderos en el momento programado. Si el registro cambia y ya no cumple los criterios, Salesforce cancela automáticamente la acción pendiente.

En este caso:

El criterio exigía que el estado de la oferta ≠ Entrevista.

El día 10, el estado cambió a Entrevista.

Como el criterio ya no se cumple, la acción programada de publicar en Chatter se cancela.

Opción A es incorrecta: no existe “pausa” para acciones programadas.

Opción B es incorrecta: la acción no se ejecuta de inmediato al cambiar el estado.

Opción C es incorrecta: no se enviará en 30 días porque la condición ya no se cumple.

Un Filtro de panel permite a los usuarios filtrar dinámicamente los datos en el panel por campos específicos como origen del caso, estado o propietario, sin necesidad de crear múltiples paneles.

Bucket Column se usa en informes para agrupar valores en categorías, no para filtrar paneles.

Componente de panel es solo una visualización (gráfico, tabla, métrica), no un filtro.

Gráfico combinado es un tipo de gráfico, no una opción de filtrado.

Por lo tanto, la forma correcta de permitir a los agentes profundizar en el panel por origen, estado o propietario es añadir un Filtro de panel.

Cuando se crea un caso manualmente en Salesforce, aparece una casilla llamada “Assign using active assignment rules”. Si está seleccionada, Salesforce aplicará las reglas de asignación activas, incluso para casos manuales.

En este escenario, la regla de asignación del administrador está enviando los casos a la Cola de Casos Automatizados, por eso los casos manuales terminan con el propietario incorrecto.

Opción A es incorrecta porque las reglas de asignación no se aplican en paralelo; solo se ejecuta un conjunto de reglas.

Opción C no aplica, ya que el problema no es un campo faltante.

Opción D es incorrecta porque las reglas de escalamiento no reasignan propiedad al crear casos, solo actúan después de que el caso lleva demasiado tiempo abierto.

Los Permission Sets son la forma recomendada de otorgar permisos adicionales a un grupo de usuarios sin tener que modificar sus perfiles.

Un Rol (A) solo controla la visibilidad de registros en la jerarquía, no da acceso a objetos.

El Manual Sharing (B) se usa para registros individuales, no para acceso global al objeto.

Crear un nuevo perfil (D) sería innecesario y poco eficiente. Salesforce recomienda: perfil = acceso base y permission sets = permisos adicionales específicos.

Con el Lightning App Builder se pueden crear y personalizar:

– Páginas de registro (Record Pages).

– Páginas de aplicación (App Pages).

La opción Página de usuario (B) no existe como tipo de página.

Los Dashboards (D) se crean en la funcionalidad de Informes y Dashboards, no en Lightning App Builder.

En Salesforce, los tipos de registro y layouts de página son los que permiten mostrar diferentes valores de picklist a distintos usuarios.

B: Usando dos tipos de registro (Ventas y Marketing) y un solo picklist, se pueden definir valores diferentes para cada uno.

D: También se puede asignar un layout distinto (con picklists diferentes) según el perfil del usuario.

A: Los permission sets no controlan valores de picklist.

C: Con un único tipo de registro no se puede diferenciar los valores del picklist.

Para tener diferentes etapas (picklist) y diferentes diseños de página, la solución es Tipos de registro + Procesos de venta.

El Proceso de venta define qué valores de etapa se muestran.

El Tipo de registro permite asociar ese proceso a un diseño de página específico y a ciertos perfiles.

B no aplica (solo afecta al acceso a registros).

C no puede controlar las etapas, solo la disposición de campos.

D no resuelve la necesidad, solo validaría datos.

En Salesforce, se puede cambiar un campo de número automático a texto sin perder los valores existentes. Todos los valores actuales del número automático se mantienen tal cual; sin embargo, después de convertirlo a texto, los nuevos registros ya no generarán automáticamente un número — habrá que introducirlo manualmente o usar automatizaciones para rellenarlo.

Opción A es confusa, ya que no hay conversión, simplemente se conservan los valores.

Opción B es incorrecta porque Salesforce sí permite cambiar de número automático a texto.

Opción C es incorrecta porque no se eliminan los valores al hacer el cambio.

Flow Builder permite crear una automatización que actualice registros relacionados — en este caso, los productos de oportunidad — cuando se cumplan ciertas condiciones, como que la etapa de la oportunidad cambie a “Closed Won”. El flujo podría:

1. Activarse cuando una oportunidad se actualice a Closed Won.

2. Recuperar los registros de productos de oportunidad relacionados.

3. Actualizar el campo de descuento de cada producto con el valor del registro de oportunidad.

– Proceso de Aprobación sirve para enviar registros a aprobación, no para actualizar registros en masa.

– Macro predefinida se usa en Service Console para tareas repetitivas de interfaz, no para automatizar actualizaciones de datos.

– Campo de Fórmula calcula valores dinámicamente pero no actualiza registros físicos; solo muestra el descuento.

Al crear una regla de validación en Salesforce, hay dos elementos principales que se deben definir:

1. Fórmula de condición de error — Es la lógica que determina cuándo debe activarse la regla de validación (evalúa como TRUE).

2. Ubicación del mensaje de error — Indica dónde aparecerá el mensaje de error (en la parte superior de la página o junto a un campo específico).

– Tipo de retorno de fórmula no es un ajuste que se elija al crear la regla; siempre devuelve un valor booleano (TRUE o FALSE).

– Fecha de activación de la regla no existe como característica; la activación se controla activando o desactivando la regla, no mediante una fecha.

Email-to-Case es la funcionalidad estándar de Salesforce para convertir automáticamente correos electrónicos entrantes en casos. Al configurar Email-to-Case, el administrador puede asociar distintas direcciones de correo electrónico con colas de casos específicas. Esto garantiza que los casos se asignen directamente a la cola correcta sin necesidad de automatización adicional.

Opción A (servicio de correo personalizado) no es necesaria porque Salesforce ya ofrece Email-to-Case.

Opción B (flujo) podría usarse para enrutamientos más complejos, pero no es necesario cuando la asignación a colas puede hacerse directamente.

Opción C (reglas de escalamiento) se usan para casos que permanecen abiertos demasiado tiempo, no para la asignación inicial.

Cuando se crea una acción programada en Process Builder (o en Flujos con rutas programadas), esta se agenda para ejecutarse solo si los criterios siguen siendo verdaderos en el momento programado. Si el registro cambia y ya no cumple los criterios, Salesforce cancela automáticamente la acción pendiente.

En este caso:

El criterio exigía que el estado de la oferta ≠ Entrevista.

El día 10, el estado cambió a Entrevista.

Como el criterio ya no se cumple, la acción programada de publicar en Chatter se cancela.

Opción A es incorrecta: no existe “pausa” para acciones programadas.

Opción B es incorrecta: la acción no se ejecuta de inmediato al cambiar el estado.

Opción C es incorrecta: no se enviará en 30 días porque la condición ya no se cumple.

Cuando los usuarios de Salesforce necesitan acceder a datos almacenados en un sistema externo, la mejor práctica es usar Objetos Externos mediante Salesforce Connect. Los objetos externos reflejan datos que residen fuera de Salesforce (como información de envíos), y el administrador puede mostrarlos en la interfaz añadiendo una pestaña personalizada.
De esta forma, los agentes de soporte pueden consultar los registros de envíos directamente desde Salesforce sin necesidad de duplicar o importar los datos.

Opción A no aplica; las vistas divididas sirven para navegar registros, no para integrar sistemas externos.

Opción C solo da control sobre vistas de lista, pero no permite acceder a datos externos.

Opción D asume que los registros de envíos existen dentro de Salesforce, lo cual no ocurre en este caso.

Cuando una organización implementa My Domain, Salesforce recomienda que todos los usuarios accedan mediante la URL personalizada (ejemplo: https://nto.my.salesforce.com). Sin embargo, durante el periodo de transición, es común que los usuarios sigan usando https://login.salesforce.com.

Para permitir un periodo de gracia y al mismo tiempo guiar a los usuarios a actualizar sus marcadores, el administrador debe configurar la Política de Redirección como Redirigir con advertencia. De este modo:

Los usuarios que intenten iniciar sesión con la URL antigua serán redirigidos automáticamente al dominio personalizado.

Además, verán una advertencia que les recuerda actualizar sus marcadores.

Opción A no ayuda, ya que no redirige a los usuarios.

Opción B y C bloquean el acceso desde la URL antigua sin dar un periodo de gracia.

Opción D es la correcta porque ofrece redirección más advertencia = periodo de transición.

Las Reglas de Asignación de Casos permiten asignar automáticamente los casos nuevos a una cola o a un usuario en función de criterios como campos de la cuenta, el origen del caso o campos personalizados.

En este escenario:

Casos de cuentas Silver/Gold → Cola de Soporte Regular

Casos de cuentas Platinum → Cola de Soporte Prioritario

Esto es precisamente lo que permiten las Reglas de Asignación.

Reglas de Workflow sirven para actualizar campos o enviar notificaciones, no para asignar casos a colas.

Reglas de Casos no existen como funcionalidad; es un distractor.

Reglas de Escalamiento se usan cuando un caso permanece abierto demasiado tiempo, no para la asignación inicial.

Con una jerarquía de campañas, cada campaña mensual se enlaza a una campaña principal (ej. “Serie de Networking 2025”).

Esto permite reportar por evento individual (mes) y también por toda la serie en conjunto, incluyendo ROI.

Los tipos de registro (A) no ayudan en los reportes de ROI.

Crear campañas con el mismo nombre (B) genera confusión y no facilita los reportes.

Los estados de miembros (D) sirven para controlar asistencia o estatus (invitado, asistió, no asistió), pero no para ROI.

No puedes desactivar un usuario si:

– Es el único destinatario de una alerta de flujo de trabajo.

– Está configurado en un campo de jerarquía personalizada (por ejemplo, un campo de aprobador).

Que sea el rol más alto (B) no importa, el rol puede quedar vacío.

Ser parte de la jerarquía de territorios (D) tampoco bloquea la desactivación.

La mejor práctica es usar Record Types junto con Page Layouts.

Así, los agentes verán un layout con los campos apropiados cuando se trate de una casa, y otro distinto con los pasos extra cuando sea un condominio.

Con un solo layout (A o D), no se puede diferenciar bien entre casas y condominios.

Tener solo campos distintos (B) tampoco es la solución óptima.

Con Flow Builder el administrador puede crear un flujo guiado de pantallas (screen flow) que divida los campos en pasos más simples y manejables.

Esto evita mostrar todos los campos a la vez y mejora la experiencia del usuario.

Las reglas de validación (A) solo controlan errores, no simplifican.

Los workflow rules (B) ya no se recomiendan y no sirven para la interfaz.

Los procesos de aprobación (D) son para aprobaciones, no para simplificar formularios.

El objetivo es distinguir los leads creados por becarios de los demás.

Esto se consigue con tipos de registro, que permiten diferenciar categorías de leads y usarlas en informes y procesos.

La opción A no sirve porque solo cambia la interfaz.

La opción B es para leads que entran por formulario web, no aplica aquí.

La opción D ayuda a asignar leads, pero no a diferenciarlos por origen.

El campo Geolocalización permite almacenar latitud y longitud, lo cual es perfecto para rastrear ubicaciones y envíos.

Búsqueda externa se usa para enlazar datos externos, no para coordenadas.

Dirección personalizada almacena direcciones físicas, pero no coordenadas precisas.

Geofence no existe como tipo de campo en Salesforce.

Se necesita un objeto personalizado para gestionar los diseños de zapatos.

La relación más adecuada es maestro-detalle entre Producto (maestro) y Diseño de Zapato (detalle), porque así se pueden crear campos resumen (roll-up) que muestren cuántos diseños tiene un producto.

Lookup (opción B) funciona, pero no permitiría los roll-up summary directamente.

C no aplica porque no existe un objeto estándar para “diseños”.

Flow Builder es la única herramienta de automatización en Salesforce que permite crear screen flows — pantallas interactivas que permiten a los usuarios introducir y visualizar datos en tiempo real. En este caso, una calculadora de descuentos necesita interacción del usuario, lo cual no es posible con Process Builder, Workflow Rules o Platform Events.

Process Builder y Workflow Rules están diseñados para acciones automáticas en segundo plano, no para mostrar pantallas.

Platform Events se usan para arquitectura basada en eventos, no para crear elementos de interfaz de usuario.

Un conector de error en Flow Builder permite al administrador manejar errores de forma clara, guiando al usuario cuando ocurre un problema. En lugar de mostrar un mensaje técnico por defecto, se puede configurar una pantalla que explique claramente la causa del error y cómo resolverlo — en este caso, pidiendo al usuario que introduzca más información en la cuenta antes de iniciar el flujo.

Opción A (Conjunto de permisos) no resuelve el problema de datos.

Opción B (Eliminar reglas de validación) no es recomendable, ya que compromete la calidad de los datos.

Opción C solo oculta el mensaje de error, pero no mejora la experiencia del usuario ni soluciona la causa.

Lo más común en un error de aprobación es que el usuario siguiente en la cadena de aprobación no esté activo o no exista.

B no afecta al flujo de aprobación.

C podría ser una solución alternativa, pero no es lo primero que se debe revisar.

D es irrelevante porque la visibilidad del campo no genera error en la aprobación.

El External ID permite identificar registros externos en Salesforce y hacer upsert (insert/update) de datos al comparar registros entre Salesforce y otro sistema.

A se limita a Salesforce, no sirve para integración.

B sirve para acceder a datos en tiempo real (Salesforce Connect), pero no para actualización directa.

C es solo una herramienta de carga, no define cómo se relacionan los registros.

Para ver una pestaña en Salesforce, el usuario debe tener permiso a nivel de objeto (al menos “Lectura”) otorgado a través de su perfil o un conjunto de permisos.

A (regla de uso compartido) afecta la visibilidad del registro, no la posibilidad de ver la pestaña del objeto.

C (jerarquía de roles) controla la herencia del acceso al registro, no la visibilidad del objeto.

D (OWD privado) controla el acceso a nivel de registro; sin embargo, si el perfil no permite el acceso al objeto, la pestaña ni siquiera se mostrará.

La funcionalidad estándar Contactos con múltiples Cuentas permite relacionar un contacto con varias cuentas sin duplicarlo.

Así se mantiene el historial y la relación correcta aunque el contratista cambie de agencia.

Crear contactos duplicados (B) no es recomendable.

Un objeto intermedio (A) no es necesario porque Salesforce ya resuelve este caso.

La comunidad de partners (D) no aplica aquí.

Para compartir registros con un grupo en Chatter, primero debe crear un grupo de colaboración (lo cual debe realizar manualmente un administrador o usuarios con los permisos necesarios, no automáticamente).

Para que los usuarios agreguen registros a un grupo, la opción “Agregar registro” debe estar disponible en el publicador del grupo.

La opción B es incorrecta porque Salesforce no crea grupos automáticamente para cada departamento.

La opción D no es necesaria específicamente para habilitar el uso compartido; es simplemente una mejora de la interfaz de usuario.

Una Regla de Validación (Validation Rule) permite aplicar lógica de negocio para impedir que los usuarios guarden un registro cuando no cumple ciertos criterios. En este caso, sirve para evitar que un usuario cambie el estado de un Case a un valor anterior en el proceso.

Las Listas de selección dependientes (Dependent Picklists) solo controlan qué valores se muestran en función de otro campo, pero no bloquean que un valor sea anterior o posterior.

Las Listas de selección globales (Global Value Picklists) permiten reutilizar valores estandarizados en varios objetos, pero no controlan la secuencia de estados.

Los Valores de campo predefinidos (Predefined Field Values) simplemente asignan un valor inicial a un campo al crear el registro, sin restricciones sobre los cambios posteriores.

Una Regla de Validación es la opción adecuada porque permite exigir condiciones antes de guardar un registro.

En este caso, la condición es: si la Etapa = “Closed Won”, entonces Lead Source no puede estar vacío.

Si los usuarios intentan guardar una Oportunidad como Closed Won sin haber completado el Lead Source, Salesforce mostrará un mensaje de error y no permitirá guardar.

A. No es posible hacer que Lead Source dependa de Opportunity Stage, porque Stage es un campo estándar que no puede usarse como campo controlador.

C. Poner Stage como solo lectura en el layout bloquearía siempre la edición, no solo bajo esta condición.

D. Opportunity Stage tampoco puede configurarse como campo dependiente de Lead Source.

C. Agregar la lista relacionada Campaign Member Statuses al Page Layout: La gestión de los estados de miembro de campaña se hace desde el registro de la campaña (Lightning: lista relacionada; Classic: Advanced Setup). Si la lista no está en el layout, no se puede acceder a la pantalla para añadir/editar estados. Por eso este paso es necesario para poder mantener los valores.

D. Modificar el valor del picklist en la lista relacionada Campaign Member Statuses: Aquí es donde realmente añades, renombras, defines el predeterminado y reordenas los estados (p. ej., “Upsell Promo”). Los cambios aplican por campaña y puedes optar por reemplazar los estados de los miembros existentes.

A. Editar los valores del picklist en Object Manager: El “Status” de Campaign Member no se administra como un picklist estándar en Object Manager; los valores utilizables se gestionan desde la lista relacionada en la campaña.

B. Modificar en masa la lista relacionada: No existe una función nativa para definir/crear valores en masa aquí. (Sí puedes actualizar en masa los estados de los miembros, pero eso es distinto a modificar la lista de valores disponibles).

El campo High Value Customer es un campo de tipo checkbox. Estos campos son Booleanos y solo pueden tener dos valores: True o False.

Para evaluarlos en un elemento de decisión en Flow, se debe configurar:

– Campo: High Value Customer

– Operador: Equals (igual)

– Valor: {!$GlobalConstant.True}

De esta manera, el flujo comprobará si el checkbox está marcado (True), y si lo está, se saltará la primera pantalla y dirigirá al usuario directamente a la segunda.

A: Contains se usa con colecciones de texto, no con valores booleanos.

B: “High Value Customer” es el nombre del campo, no un valor de tipo Booleano.

C: Igual que A, contains no aplica a campos checkbox.

B. Seguridad a nivel de campo: Asegura que el gerente de ventas pueda ver los campos necesarios en el informe. Si los campos están ocultos por FLS, los datos no aparecerán aunque tenga acceso a los registros.

D. Acceso a la carpeta: El informe se guarda en una carpeta. Para verlo, el gerente necesita permiso de acceso a dicha carpeta.

E. Jerarquía de roles: Como el OWD está en Privado, la jerarquía de roles permite que el gerente de ventas (nivel superior) pueda ver los registros propiedad de sus subordinados (los representantes de ventas).

A. Suscripción de informe: Solo programa y envía por correo el informe; no otorga acceso.

C. Tipo de informe personalizado: Define qué objetos y campos están disponibles en los informes, pero no controla el acceso a los datos ni a los informes.

ID externo: Es la opción correcta porque permite a Salesforce hacer coincidir registros usando un identificador de otro sistema (como uno financiero o de ERP). Garantiza que los registros se puedan insertar, actualizar o hacer upsert correctamente sin depender de los IDs internos de Salesforce.

Campo de texto enriquecido: No es adecuado porque se usa para texto con formato, no como identificador único.

Campo de número automático: Genera números únicos dentro de Salesforce, pero no se vincula con los identificadores de sistemas externos.

ID de registro: Aunque es único en Salesforce, no se puede usar de forma fiable en sistemas externos, ya que esos sistemas no conocen los IDs de Salesforce.

A. Desde el panel de campos, arrastrar el campo a la misma posición: Correcto, porque quitar un campo del diseño no lo elimina del sistema, siempre puede volver a añadirse desde el panel.

D. Restaurar el diseño de página original desde un sandbox: Correcto, ya que se puede desplegar o copiar el diseño desde un sandbox si es necesario.

B. Restaurar desde la papelera de reciclaje en 15 días: Incorrecto, porque quitar un campo del diseño no lo borra, por lo tanto, nunca va a la papelera.

C. Clonar el diseño de otro perfil y usar guardar como: Incorrecto, porque clonar otro diseño no garantiza restaurar el estado exacto anterior del diseño original.

C. Configuración regional de moneda: Correcto, porque los ajustes de compañía incluyen la configuración de moneda predeterminada de la organización.

D. Idioma predeterminado: Correcto, porque los ajustes de compañía también incluyen el idioma predeterminado de la organización.

A. Horas de inicio de sesión: Incorrecto, ya que se configuran a nivel de perfil, no en los ajustes de compañía.

B. Política de contraseñas: Incorrecto, porque se configura aparte y no forma parte de la información de compañía.

A. Marcar campos como obligatorios en el diseño de página: Garantiza que el usuario no pueda guardar el registro sin completar los campos clave.

C. Usar reglas de validación: Permite aplicar condiciones lógicas para reforzar reglas de negocio y evitar guardar datos incompletos o inválidos.

E. Configurar Opportunity Path: Ayuda a guiar al usuario en cada etapa del proceso de ventas y resalta los campos clave que deben completarse en ese momento.

B. Usar Flow para marcar campos obligatorios: Incorrecto, los Flows no son el mecanismo principal para esto; la mejor práctica son reglas de validación y page layouts.

D. Habilitar venta guiada: Incorrecto, la venta guiada se usa en CPQ y no aplica a la gestión estándar de Oportunidades.

La forma adecuada de mostrar un flujo de pantalla en un Caso es incrustarlo en la Lightning Record Page del objeto Case.

Así, los agentes de servicio pueden acceder y ejecutar el flujo directamente desde el Caso, sin necesidad de cambiar de vista.

Página de inicio es incorrecta porque el flujo no estaría ligado a Casos, sino a la página principal.

Diseño de página es incorrecto porque los diseños gestionan campos y secciones, no permiten incrustar flujos.

Filtro de componente es incorrecto porque solo controla visibilidad, no la distribución del flujo.

Cuando se necesita que los usuarios vean valores de picklist distintos según el tipo de oportunidad, esto se gestiona con los Tipos de Registro.

Los Tipos de Registro permiten asignar diferentes subconjuntos de valores de un mismo picklist según el proceso o categoría de negocio.

Campos y relaciones solo define el campo, no controla qué valores se muestran en cada situación.

Conjuntos de valores de lista establecen el catálogo global de opciones, pero no permiten diferenciarlas por tipo de oportunidad.

Filtros de búsqueda relacionados solo aplican a campos de búsqueda (lookup), no a listas desplegables.

Omni-Channel permite enrutar automáticamente los casos (y otros elementos de trabajo) a los agentes en función de su capacidad (carga de trabajo disponible) y sus habilidades (quién está más calificado para resolver el caso).

Gestión de Territorios aplica a cuentas y oportunidades, no al enrutamiento de casos.

Reglas de Escalamiento reasignan casos después de ciertos plazos o condiciones, pero no toman en cuenta la carga de trabajo ni las habilidades del agente.

Gestión del Conocimiento proporciona artículos y recursos de soporte, pero no asigna casos.

Cuando la opción Lista desplegable restringida está desmarcada, Salesforce permite importar valores que no están definidos en la lista (como “Unrated”).

Si fuera una lista desplegable restringida, la importación de “Unrated” habría generado error.

Las opciones B y C se relacionan con disponibilidad o visibilidad, pero no permiten valores no listados.

La opción D no justifica por qué se aceptó “Unrated”.

Una regla de validación es la mejor opción para requisitos condicionales, como obligar a llenar “Loss Reason” solo si la oportunidad está en estado Cerrada Perdida.

La opción A es incorrecta porque las reglas de flujo de trabajo no pueden mostrar mensajes de error.

Las opciones C y D harían que el campo fuera obligatorio siempre, incluso cuando la oportunidad no está perdida.

La regla de validación permite controlar exactamente cuándo debe completarse el campo.

Los criterios de evaluación de las reglas de los workflows siempre incluyen cuando un registro fue creado.

Lightning Sync puede ser utilizado para sincronizar contactos y eventos entre Salesforce y Microsoft Exchange. Los Emails no pueden ser sincronizados utilizando Lightning Sync, pero sí pueden ser adjuntados a múltiples contactos o registros.

Para asegurarse de que todos los usuarios tienen que rellenar un campo en el momento de creación del registro, tanto de manera manual como por un proceso de carga o automatizado, se deberá establecer como un campo obligatorio a nivel de seguridad de campo.

Utilizando las reglas de colaboración se podrán otorgar permisos a grupos de usuarios para que puedan visualizar registros de otros usuarios o de roles que no estén asignados a su jerarquía.

A través de las reglas de escalado se van a poder automatizar acciones en función del tiempo que se haya marcado sin que un caso esté resuelto. Será posible modificar el propietario de un caso o crear notificaciones para los usuarios de los responsables.

A través de las reglas de asignación se puede automatizar que un caso, en función a unas condiciones que se marquen, se cree a un usuario o a una cola.

Para poder automatizar el envío de comunicaciones a los clientes en un entorno de Salesforce es necesario, primero, crear una plantilla de email personalizada y con la marca de la compañía y, segundo, crear reglas de auto respuesta para automatizar el envío de los emails una vez se haya creado un caso.

La aplicación nativa de Salesforce permite a los usuarios hacer las mismas acciones y ver la misma información que en la versión de escritorio. La única funcionalidad a la que no se puede acceder es a la consola de desarrollo, enfocada para la utilización de código.

Como los perfiles estándar no pueden borrarse ni modificarse, para poder cubrir esta necesidad será necesario crear un perfil nuevo en el que se le deshabilite la posibilidad de borrar registros de cuentas y asociar este perfil a los usuarios correspondientes.

A través de la relación de tipo Master-detail se crea una dependencia entre registros de los objetos. De esta manera, para poder crear un registro de un objeto hijo, necesita tener asociado un objeto padre de manera obligatoria. De la misma manera, si un registro del objeto padre es eliminado, como en este caso, el registro del objeto hijo también.

Los usuarios que tengan permiso para crear o editar un objeto, así como los administradores, podrán actualizar un registro que tenga un usuario inactivo como propietario.

Una vez que un campo personalizado es borrado, puede ser recuperado en un período de 15 días.
El borrado de campos personalizados puede acelerarse utilizando el borrado total para liberar antes la asignación de campos personalizados.

Con el soporte de informes unidos en Lightning Experience, uno podrá crear y convertir informes no unidos en informes unidos, renombrar y reorganizar el orden de los bloques de informes, crear fórmulas de resumen de bloques cruzados, que son campos de fórmula que pueden acceder y utilizar valores de cualquiera de los informes disponibles en los informes unidos.

Una cuenta personal es un consumidor individual con el que se hacen negocios. Las cuentas personales son utilizadas por organizaciones que operan con un modelo de negocios de B2C.
Además, las cuentas pueden ser utilizadas como clientes o como competidores.

Una regla de asignación del caso puede tener varias reglas de entrada. Solo una regla de asignación puede estar activa al mismo tiempo. Al activar una regla de asignación, desactivará otra de manera automática.

Dado que las reglas de colaboración es lo que se necesita en este escenario, y las reglas de colaboración no pueden ser creadas para compartir registros con usurios específicos, un grupo público con el usuario incluido tiene que ser creado.
Además, como solo algunos registros tienen que ser compartidos, la regla de colaboración tiene que ser de criterios especificados por el director de ventas.

Cuando un Lead es cualificado y convertido, pueden seleccionarse cuentas y contactos ya existentes o crearse nuevos registros. La creación de una oportunidad es opcional.
Los Leads pueden ser contactos que estén relacionados con una cuenta o consumidores individuales.
Además, pueden ser importados a través de un fichero o de manera automática con un Web-to-Lead, por ejemplo.

Una regla de duplicidad usa una regla de emparejamiento para identificar contactos que se consideran duplicado, y múltiples reglas de duplicidad pueden ser activadas al mismo tiempo en el mismo objeto. Se pueden utilizar varios campos en las reglas de emparejamiento. Las acciones de bloquear o permitir se establecen en la regla de duplicidad

El tipo de campo de hora puede almacenar un valor de hora que no esté vinculado a una fecha. Se puede seleccionar una hora del día.
En este caso se crearían dos campos, uno para la hora de entrada y otro para la hora de salida.

Las reglas de asignación de casos se utilizan para especificar los casos que tienen que ser asignados a usuarios o colas específicas. Las reglas de escalado se utilizan para reasignar casos o notificar cuando los casos no son resueltos.

Si la regla de colaboración del objeto Cuentas está marcado como ‘privado’, los registros del objeto solo podrán ser vistos por los propietarios de los registros. Sin embargo, ‘Permitir acceso utilizando la Jerarquía’ dará acceso a los usuarios que se encuentren por encima en la jerarquía de roles.
Dado que no se puede desactivar para objetos estándar, la jerarquía tendrá que configurarse de tal manera que el rol Director de ventas global no se encuentre en la parte superior de la jerarquía. De lo contrario, el Director de ventas global tendrá visibilidad de todas las cuentas.

Al configurar un único usuario, el email y el nombre de usuario pueden ser distintos. Al configurar varios usuarios, el email se convierte en el nombre de usuario. Los perfiles disponibles dependen de la licencia que se asigne.
Un usuario puede tener solo un rol y un perfil asignados.

Hacer coincidir a través de un ID externo es posible en cualquier objeto que tenga un ID externo y pueda ser importado a través de Data Import Wizard. Cuando la opción de coincidir a través del ID externo es seleccionado, Data Import Wizard detecta los registros existentes en Salesforce con ID externo que encajen con los valores especificados en el fichero de carga.

Un administrador puede navegar a ‘Time-Based Workflow’ a través del Setup para visualizar y cancelar cualquier acción de tiempo pendiente de un Workflow que esté añadido en la cola.

En Salesforce Classic, un administrador puede hacer que los filtros de búsqueda sean obligatorios u opcionales. En Lightning Experience, todos los filtros de búsqueda son obligatorios, incluso si es están marcados como opcionales. Si se define un filtro de búsqueda en un campo de búsqueda, será “obligatorio” en Lightning Experience, lo que significa que un usuario sólo puede elegir un valor que cumpla los criterios del filtro.
Los filtros de búsqueda se utilizan para filtrar los registros que se van a visualizar. Pueden hacer referencia a campos tanto del objeto de origen como del objeto de destino. Los filtros de búsqueda también pueden hacer referencia a campos de registros relacionados con el objeto de destino o a campos relacionados con el usuario.

Los componentes pueden ser añadidos, editados, reorganizados o eliminados de un registro de página a través de Lightning App Builder.
Generalmente, los componentes no puedes reajustarse el tamaño a no ser que la propiedad esté habilitada.

En Lightning Experience, las opciones de ‘Gestión de los miembros de campaña’ y de ‘Importar Leads y Contactos’ aparecerán como opciones en el Data Import Wizard. Data Import Wizard puede usarse para añadir o actualizar hasta 50.000 registros de miembros de campaña.

Un flujo puede ser utilizado para cambiar el tipo de registro de la Oportunidad cuando el campo etapa es actualizado a ‘Cerrado ganado’. Un formato de página que no tiene asignado el botón borrar puede ser asignado al tipo de registro para todos los perfiles, excepto para el VP de ventas.
Para evitar que un registro sea borrado en una lista relacionada, puede utilizarse una regla de validación. La regla de validación en un objeto padre, utilizaría campos de resumen desplegables para comparar el número de oportunidades cerradas antes y después de que se borrara el registro y, si es diferente, evitar la eliminación.

Backup & Restore es un producto de Salesforce que permite generar backups y restaurar datos en el momento que hay errores de integración, ataques maliciosos o actualizaciones incorrectas de datos. Sirve tanto para objetos estándar como personalizados.

Los valores de una lista de selección se pueden definir de manera separada para cada tipo de registro, no tienen que ser añadidos a todos los tipos de registro. Cuando los valores de una lista de selección son añadidos, ellos son incluidos como activos y no necesitan ser activados.

En Lightning Experience, los usuarios pueden trabajar con el objeto actividades a través de una lista relacionada o a través del ‘Calendario de Actividades’. El administrador de Salesforce puede establecer una vista por defecto de las actividades, pero los usuarios pueden cambiarla en su configuración personal. Si ‘Einstein Activity Capure’ está habilitado, el ‘Calendario de Actividades’ es obligatorio.
Si una tarea es creada en el registro de un contacto, la tarea se verá en el ‘Calendario de Actividades’ del contacto y de la cuenta relacionada. También se podrá visualizar en la vista de lista ‘Mis Tareas’.

Si un usuario está logueado y el tiempo de poder estar en el entorno termina, el usuario podrá continuar viendo al información de la página en la que está, pero en el momento que intente hacer cualquier acción será expulsado del entorno.

La relación de tipo Master-detail es utilizada para hacer un modelo relación de muchos con mucho entre objetos. Un objeto unión es un objeto personalizado que se relaciona con dos relaciones de tipo Master-detail y es utilizado para relacionar dos objetos entre sí.
Estos dos son necesarios para poder construir una relación de muchos a muchos entre dos objetos personalizados. El objeto unión se utiliza para poder relacionar dos objetos que tienen que tener una relación de muchos a muchos. El objeto unión tiene un campo de tipo Master-detail con cada uno de los objetos que relaciona.

‘Mi Dominio’ permite a los administradores de Salesforce definir subdominios para la URL de su entorno. El subdominio definido sustituye al pod de instancia en todas las URL dentro de la org. Mi Dominio es requerido por algunas funcionalidades como la de Single SIgn-On y ciertos componentes Lightning personalizados, así como algunos paquetes manejados.

Cuando un evento es creado manualmente desde Gmail (cuando la Integración es con Gmail), cualquier registro que coincida será automáticamente seleccionado si Salesforce está configurado para compartir actividades. Un administrador debe asegurar que está activa la opción ‘Permitir a los usuarios relacionar múltiples contactos con tareas y eventos’ dentro del Setup de Salesforce en la opción ‘Configuración de Actividades’. Es posible relacionar una actividad con hasta 50 contactos o un lead. Sin embargo, la integración solo muestra los 15 primeros registros en el orden que aparecen en el evento.
Todos los asistentes a una invitación pueden ser incluidos en un evento de un registro de Salesforce confirmando que el campo “Asistentes” está disponible en el formato de página del objeto Evento.
No es posible enlazar eventos con usuarios internos.

La plantilla de Email tiene que ser marcada como ‘disponible para el uso’ para que los usuarios puedan utilizarla. Las plantillas de Email se pueden crear para que estén disponibles para todos los usuarios o solo para ciertos grupos de usuarios o roles en función de los accesos otorgados a las carpetas de las plantillas de Email.

La ruta de ventas muestra el estado de la oportunidad, los campos claves a rellenar e información relevante de cada etapa como pueden ser links a Chatter, posts y archivos. La oportunidad pasa automáticamente a la siguiente etapa, una vez se marca como completada la etapa actual.

Una URL customizada puede ser creada para un dashboard añadiendo parámetros en la URL del dashboard original. Cuando un usuario accede a la URL personalizada, el dashboard se abre con los filtros ya establecidos. Para añadir un filtro en el dashboard original, puede añadirse el parámetro (fv0) y el valor (=100000). EL valor ‘fv’ se establece para el valor del filtro. El número (0) en el parámetro indica el orden en el que aparece el dashboard. Como solo hay un filtro, ‘fv0’ debería utilizarse como parámetro en el filtro. el carácter ‘&’ denota un nuevo parámetro en la URL. Como consecuencia, la URL modificada debería verse como ‘https://my-domain-name.lightning.force.com/lightning/r/Dashboard/01>6g00000Rw4zEAC/view?queryScope=userFolders&fv0=100000’

Para cumplir con este requerimiento, un registro variable con el nombre “recordid” tiene que ser creado en el flow. Esta variable debería de estar disponible como entrada. La acción rápida en la página de Lightning debería pasar el registro a este registro variable. El flujo puede acceder al registro para obtener la información requerida para enviar el email, por lo que no es necesario añadir la acción “obtener registro” al flow para obtener el registro del almacén.

Los objetos Candidatos, campañas, oportunidades y pedidos son objetos relacionados con la venta. El resto de objetos mencionados como Casos o contratos de servicio son objetos de soporte.

La localización por defecto se encuentra en la información de la compañía y establece la forma de visualizar las fechas, el tiempo y los números en el entorno. Se establece en la información de la compañía, pero puede ser modificado por cada usuario.
Con este enunciado, lo más eficiente sería notificar a los usuarios afectados y que ellos cambien su localización en la configuración de su usuario.

Las acciones de los workflows (“flujos de trabajo” incluyen actualizar campos, crear tareas, alertas de email y mensajes salientes. No hay acciones de workflows que sean crear eventos, crear registros y plantillas de email.
Desde la actualización de Winter’23 Salesforce recomienda el uso de Flows para la creación de acciones automatizadas en la plataforma.

Siguiendo las reglas de ejecución establecidas por Salesforce, el orden sería: reglas de validación, reglas de auto-respuesta, reglas de Workflows y reglas de escalado.

El primer paso que se tiene que seguir siempre para este tipo de requerimientos es ir al mercado de aplicaciones propio de Salesforce, Appexchange.

Las alertas de email utilizan plantillas de email que necesitan ser configuradas antes de crear la alerta. Las alertas de email pueden ser enviadas a usuarios, roles, propietarios de registros o a grupos públicos.

Utilizando la funcionalidad de incluir valores nulos, usando Data Loader, se pueden cargar campos sin información. Los campos en blanco en un fichero .csv son tratados como campos que no tienen que ser modificados por Data Loader y, por lo tanto, el valor no cambiaría de Nuevo a vacío.
Esta opción viene desmarcada por defecto, hay que activarlo.

El propietario de un caso puede ser modificado por el actual propietario del caso, cualquier usuario con un rol superior y por otros usuarios que tengan activado en su perfil la opción de “modificar todo” en el objeto caso, como el Administrador de Sistemas.

La activación de la función de ocultar información del informe en la configuración de la auto-respuesta en los “Web-to-Case”, es el único requerimiento que puede ser oculto para que un cliente no introduzca datos cuando la creación de un caso falla.

Puede crearse un informe de tipo matricial y agrupar los campos de etapa y propietario de la oportunidad en filas y columnas. El campo período fiscal puede incluirse tanto en las filas como en las columnas.

Los grupos públicos pueden contener una combinación de usuarios, roles, usuarios asignados a territorios específicos y roles y subordinados.
Perfiles y conjuntos de permisos no pueden ser asignados a los grupos públicos.

Un usuario puede ser reactivado marcando de nuevo la casilla de “Active”.

Mientras se diseñe un flujo en Flow Builder, el recurso ‘Variable’ es usado para almacenar para un único tipo de dato, como un único valor de texto. Debe asegurarse de que la casilla “Permitir valores múltiples” no esté seleccionada.
Una variable se convierte en una colección cuando este checkbox está marcado. Una colección está diseñada para almacenar varios valores.

Lightning App Builder puede ser utilizado para modificar registros de páginas existentes o nuevos tipos de páginas. El Sales Path es un componente estándar que puede ser quitado del registro de pantalla de la oportunidad.
La opción “fijar la visibilidad del componente” del “Sales Path” puede ajustarse a los criterios de filtrado. Este criterio de filtro ocultará el Sales Path para los usuarios con el perfil de Ventas.

Los pasos que hay que seguir cuando se crea un nuevo campo custom son:
– Elegir el tipo de campo.
– Introducir los detalles del campo y el texto de ayuda
– Elegir la seguridad del campo por cada perfil.
– Elegir los formatos de página que tendrán acceso.

Las Macros puede ser compatibles con todos los objetos con diseños de página basados en feeds. Activando a los macros los agentes de atención al cliente podrán hacer varias tareas de manera más ágil, solo con un click.

De las acciones incluidas en el enunciado, la que va a permitir poder introducir información en los Flows es la de Pantalla.
Las “Quick Actions” no pueden ser utilizadas en los Flows.

La combinación de crear una picklist con los valores que pueden elegir los usuarios, añadiendo una regla de validación que obligue a rellenar ese campo cuando tenga que ser completado, es la mejor opción para disponer de la información correcta y que los informes salgan bien.
Podría crearse el campo solo, pero sin la regla de validación se está asegurando que el campo tenga la información siempre

Cualquier objeto custom, como los Cases, Leads, Orders, Service Contracts y los artículos pueden ser asignados a colas. Una vez activas las colas, se crea una list view en los objetos Cases, Leads y en los objetos Custom cuando son asignados a colas.
Un objeto puede ser asignado a una cola de manera manual por un usuario y a través de reglas de asignación en el caso de Leads y Cases.
Por último, solo los miembros de una cola pueden aceptar registros que se asocien a esa cola.

El proceso de negocio que está relacionado con las oportunidades es el “Proceso de Ventas”.
El resto de procesos que aparecen están relacionados con otros objetos.

Cuando un entorno de Salesforce es configurado como privado, cada usuario solo podrá visualizar la información de los registros de los que sea propietario. Esto también afecta a los informes, los cuales se adaptarán a la información a los que el usuario sea el propietario.

Para poder permitir que múltiples cuentas estén relacionadas con un contacto, la funcionalidad ‘Contactos para Múltiples Cuentas’ debe de estar habilitada. Después de que esté habilitada, la lista relacionada de Cuentas relacionadas tiene que añadirse en el formato de página de contactos y la lista relacionada de Contactos relacionados, tiene que añadirse al formato de página de cuentas.
La lista relacionada de Contactos en el objeto cuenta puede ser eliminada ya que la nueva lista relacionada ‘Contactos relacionados’ incluirá a los contactos relacionados de manera directa e indirecta. 

Las reglas de flujo de trabajo de Salesforce pueden evaluarse utilizando estos tres criterios válidos:

Creado: se activa únicamente cuando se crea un nuevo registro.

Creado y cada vez que se edita: se activa al crear el registro y en cada edición, sin importar si vuelve a cumplir los criterios.

Creado y cada vez que se edita para cumplir posteriormente los criterios: se activa al crear el registro y cuando este pasa de no cumplir a cumplir con los criterios de la regla.

Los informes en Salesforce pueden exportarse de dos maneras disitintas, Informe con Formato o Informe con solo Detalles. Si se exporte como “Solo Detalles”, puede exportarse en formato .xls, .xlsx or .csv. En cambio, si es “Con Formato” solo puede exportarse como .xlsx

El marcador de ventas permite hacer y recibir llamadas, añadir notas a la llamada y registrar información sobre las llamadas. Las llamadas pueden realizarse pinchando en cualquier campo teléfono en los objetos contacto, leads y en las list views.
Solo está disponible para la versión Lightning. Además permite grabar las llamadas y esta función no requiere de un plugin adicional.

CTI puede recibir llamadas, grabarlas y almacenarlas para el cumplimiento de la normativa. Además, puede identificar a la persona que llama y mostrar su información.
Para las llamadas salientes, puede ofrecer marcación automática y click para llamar.
También, se pueden automatizar los mensajes de voz con IVR (Interactive Voice Response).
Como funciones avanzadas, existe la posibilidad de mostrar acciones o recomendaciones en función de los temas de la conversación.

Cuando un campo custom es borrado en Salesforce algunas de sus propiedades se pierden, por lo que tienen que volver a establecerse. Cuando ese campo es recuperado, la relación pasa a ser Look-up, por lo que habría que pasarla a Master-Detail, si fuera necesario.
Ocurre lo mismo si el campo era obligatorio, se tendría que volver a marcar como obligatorio una vez se recupere de la papelera de reciclaje, si fuera necesario.

Para conectar una cuenta de Linkedin con Salesforce, es necesario dar de alta la cuenta a través del Setup, en la sección LinkedIn Lead Gen. Salesforce se conecta a la cuenta de Linkedin Ads. Una vez establecida la conexión hay que mapear los campos de los formularios con los campos de los Leads de Salesforce para que se den de alta directamente en la plataforma desde LinkedIn.

En la versión Lightning el uso de carpetas y subcarpetas otorga a los usuarios una mejor organización a la hora de trabajar con informes y panales. Dentro de informes y de panales la acción de crear las carpetas se encuentra arriba a la derecha y solo pueden ser creadas en la sección “creadas por el usuario”.
Además, las carpetas y subcarpetas se pueden eliminar y se las puede renombrar.

Durante el proceso de configuración de un proceso de aprobación es posible establecer si el registro puede ser modificado por un administrador del sistema y/o por el aprobador.

Aunque “Public Read/Write/Transfer solo afecta los objetos de Casos y Leads, el resto de soluciones no son correctas, ya están disponibles independientemente del tipo de objeto. Están disponibles tanto en objetos estándar como en customizados.

Estas dos opciones permiten vincular una oportunidad con una campaña de manera efectiva:

• Primary Campaign Source: se utiliza para indicar la campaña principal que generó la oportunidad.
• Campaign Influence Related List: permite asociar múltiples campañas que pudieron haber influido en la oportunidad, lo cual es útil para el análisis de marketing.

En el proceso de conversión de un Lead siempre se creará una Cuenta y un Contacto (siempre que el campo Compañía dentro del Lead esté relleno) y, de manera opcional, se podrá crear una oportunidad o no.

Cada usuario puede configurar su equipo de ventas por defecto en su configuración personal. Además, cada propietario de un registro de una oportunidad, puede asignar ese equipo de la oportunidad en cualquier registro de oportunidad, en las que ellos sean los propietarios. Tanto desde la aplicación móvil como desde el escritorio.

Con los tipos de registro podemos diferenciar diferentes procesos de ventas, valores de los campos picklists y disponer de diferentes formatos de página en un objeto. La configuración de los tipos de registro se puede hacer en cualquier objeto, tanto estándar como custom. La información se visualizará en función de los permisos configurados en el perfil asignado a cada usuario.

Los campos fórmula son la mejor elección cuando se quiere traer información de un campo de un objeto “padre” a un objeto “hijo”. A través de ese campo, el objeto “hijo” trae la información de los campos del objeto “padre”, estando siempre actualizados con el valor del objeto “padre”.

En el proceso de conversión de un Lead siempre se creará una Cuenta y un Contacto (siempre que el campo Compañía dentro del Lead esté relleno) y, de manera opcional, se podrá crear una oportunidad o no.
Además, puede seleccionarse el propietario del registro.

Cuando se convierte un lead en Salesforce, puedes asociarlo con una Cuenta y/o un Contacto existentes. Esto permite que el sistema fusione la información del lead con esos registros ya existentes. Sin embargo:

• Oportunidades: Puedes crear una nueva oportunidad durante la conversión, pero no puedes actualizar una que ya exista.
• Objetos personalizados: No forman parte del proceso estándar de conversión de leads.

Esta opción permite a los Sales Managers ver y generar informes sobre todos los datos, incluidos los registros de oportunidades, sin necesidad de tener acceso a objetos personalizados como el de solicitudes de tiempo libre. En un modelo de uso compartido privado, esta es la única opción que garantiza acceso completo a los datos necesarios para informes globales, sin modificar los permisos sobre objetos específicos no relacionados

Los diseños de búsqueda son conjuntos de campos ordenados que se visualizan cuando se busca un registro. En el diseño de búsqueda se puede configurar los campos que pueden aparecer y el orden de visualización.