El modelo de colaboración de Salesforce es un elemento esencial en la capacidad de su organización para proporcionar acceso seguro a los datos de la aplicación. Por lo tanto, es crucial diseñar su modelo de colaboración correctamente para cumplir sus requisitos de acceso a datos actuales y futuros. En este documento, revisaremos componentes de accesibilidad de datos, casos de uso de modelo de colaboración y soluciones de colaboración de clientes reales, y proporcionaremos algunas directrices de solución de problemas.
Este documento está dirigido a administradores y arquitectos avanzados del sistema. Para comprender los conceptos, debe tener un Knowledge práctico del modelo de colaboración y seguridad de Salesforce. Los requisitos previos a esta guía son:
- Ayuda de Salesforce: Configuración de colaboración
- Módulo Trailhead: Seguridad de datos
- Diseño del acceso a registros para Enterprise Scale
- Salesforce bien arquitectado: seguro
Esta guía se centra en las funciones principales utilizadas para controlar el acceso a nivel de registro a objetos estándar y personalizados. Los temas no tratados en esta guía incluyen:
- Acceso a carpetas
- Acceso a contenido
- Acceso Chatter
- Acceso a la base de Knowledge
- Acceso a Ideas, Preguntas/Respuestas
- Accesibilidad a datos móviles
La seguridad a nivel de registro le permite otorgar a los usuarios acceso a algunos registros de objetos, pero no a otros. Como con la mayoría de las aplicaciones, el acceso a los datos comienza con un usuario. La aplicación debe saber quién es el usuario antes de proporcionar acceso. Para Salesforce, existen diferentes tipos de usuarios y, a veces, el nivel de acceso es diferente por tipo. En vez de revisar cada atributo de cada tipo de licencia, nos centraremos aquí en los atributos interesantes que tienen un impacto significativo en el acceso a los datos. La propiedad del registro y el acceso completo son sinónimos e intercambiables y proporcionan al usuario el nivel más alto de acceso a un registro.
Usuarios de gran volumen
Los usuarios de gran volumen (incluyendo usuarios con los tipos de licencia Comunidad de clientes, Portal de clientes de gran volumen y Sitio web autenticado) no utilizan el modelo de colaboración, porque sus tipos de licencia no admiten funciones. Estas licencias tienen su propio modelo de colaboración que funciona por coincidencia de clave externa entre el usuario (que posee la licencia) y los datos en búsquedas de Cuenta y Contacto. Los administradores pueden crear conjuntos de colaboración o grupos de colaboración para otorgar a los usuarios de gran volumen acceso a registros.
Licencias externas Chatter Free y Chatter
Las licencias Chatter Free y Chatter External no siguen el modelo de colaboración estándar. Estas licencias no tienen acceso a registros de CRM (objetos estándar o personalizados) y funciones de contenido, y no admiten funciones, por lo tanto, no hay colaboración.
Para el resto de este documento, estamos asumiendo un tipo de usuario de Salesforce que utiliza un modelo de colaboración completo. Consulte Licencias de usuario para obtener más información acerca de cada tipo de licencia disponible.
Perfiles y conjuntos de permisos
Los perfiles y conjuntos de permisos proporcionan seguridad a nivel de objeto determinando qué tipos de datos ven los usuarios y si pueden modificar, crear o eliminar registros. Para cada objeto, los permisos “Ver todo” y “Modificar todo” ignoran las reglas y configuraciones de colaboración, permitiendo a los administradores otorgar acceso rápidamente a registros asociados con un objeto concreto en toda la organización. Estos permisos son a menudo alternativas preferibles a los permisos administrativos “Ver todos los datos” y “Modificar todos los datos”, que permiten a los usuarios ver o modificar todas las aplicaciones y datos.
Los perfiles y conjuntos de permisos también controlan la seguridad a nivel de campo, que determina los campos en cada objeto al que pueden acceder los usuarios. Por ejemplo, un objeto puede tener 20 campos, pero se puede configurar la seguridad a nivel de campo para evitar que los usuarios vean cinco de los 20 campos.
Recomendamos encarecidamente que utilice conjuntos de permisos y grupos de conjuntos de permisos en vez de perfiles para gestionar los permisos de objetos de sus usuarios. Como puede reutilizar partes integrantes de conjuntos de permisos más pequeños, puede evitar crear docenas o incluso cientos de perfiles para cada usuario y función de trabajo.
Propiedad de registros y colas
Cada registro debe ser propiedad de un único usuario o una cola. El propietario tiene acceso al registro, basándose en la Configuración de objeto para el perfil del propietario. Por ejemplo, si el perfil del propietario tiene el permiso Crear y Leer en un objeto, pero no el permiso Modificar o Eliminar, el propietario puede crear un registro para el objeto y ver el nuevo registro. Sin embargo, el propietario no podrá modificar o eliminar el registro. Los usuarios de una jerarquía superior (función o territorio) heredan el mismo acceso a los datos que sus subordinados para objetos estándar. Si el subordinado tiene acceso de solo lectura, también lo tendrán los usuarios por encima de él en la jerarquía de funciones. Este acceso se aplica a registros propiedad de usuarios, así como a registros compartidos con ellos.
Las colas le ayudan a priorizar, distribuir y asignar registros a equipos que comparten cargas de trabajo. Los miembros de la cola y los usuarios que se encuentren en un nivel superior de la jerarquía de funciones pueden acceder a las colas desde vistas de lista y asumir la propiedad de los registros de una cola.
Si un único usuario posee más de 10.000 registros, como práctica recomendada:
-
El registro de usuario del propietario no debe tener una función en la jerarquía de funciones.
-
Si el registro de usuario del propietario debe tener una función, coloque la función en la parte superior de la jerarquía en su propia rama de la jerarquía de funciones.
Consulte Consultar Salesforce Well-Architected: Reliable para obtener más información.
Predeterminados de toda la organización
La configuración de colaboración de toda la organización especifica el nivel predeterminado de acceso que tienen los usuarios a los registros de los demás. Utiliza la configuración de colaboración de toda la organización para bloquear sus datos al nivel más restrictivo. Utilice las otras herramientas de colaboración y seguridad a nivel de registro para otorgar acceso de forma selectiva a otros usuarios. Por ejemplo, los usuarios tienen permisos a nivel de objeto para leer y modificar oportunidades, y la configuración de colaboración de toda la organización es Solo lectura. De forma predeterminada, esos usuarios pueden leer todos los registros de oportunidades, pero no pueden modificar ninguno a menos que sean propietarios del registro o se les otorguen otros permisos.
La configuración predeterminada de toda la organización se puede cambiar de una configuración a otra (Privada a Controlada por principal, luego de nuevo a Privada). Sin embargo, estos cambios requieren un nuevo cálculo de colaboración y dependiendo del volumen podrían dar como resultado largos tiempos de procesamiento.
Solo para objetos personalizados, puede configurar el parámetro Otorgar acceso utilizando jerarquías. Si no está seleccionada (la opción predeterminada está seleccionada), se evita que los usuarios de la jerarquía de funciones hereden el acceso. Esta configuración se encuentra en la configuración predeterminada de toda la organización.
Jerarquía de funciones
Una jerarquía de funciones representa un nivel de acceso a los datos que un usuario o grupo de usuarios necesita. La jerarquía de funciones garantiza que los gerentes siempre tengan acceso a los mismos datos que sus empleados, independientemente de la configuración predeterminada de toda la organización. Las jerarquías de funciones no tienen que coincidir exactamente con su gráfico de organización. En su lugar, cada función en la jerarquía debe representar un nivel de acceso a los datos que un usuario o grupo de usuarios necesita.
En organizaciones de Salesforce creadas en Spring ’21 o versiones posteriores, puede crear hasta 5.000 funciones. En organizaciones creadas antes de Spring ’21, puede crear hasta 500 funciones y puede ponerse en contacto con el Servicio de atención al cliente de Salesforce para aumentar este límite. Como práctica recomendada, mantenga el número de funciones internas en 25.000 y el número de funciones externas en 100.000.
Como práctica recomendada, mantenga la jerarquía de funciones en no más de 10 niveles de bifurcaciones en la jerarquía.
Cuando cambia la función de un usuario, se evalúa cualquier regla de colaboración relevante para corregir el acceso según sea necesario. Los compañeros de la misma función no les garantizan el acceso a los datos de los demás.
El modelado de la jerarquía de funciones comienza con la comprensión de cómo está estructurada la organización. Normalmente se crea a partir de la comprensión del ámbito de un gestor, comenzando desde la parte superior. El CEO supervisa toda la empresa. El CEO suele tener informes directos que luego se pueden segmentar por Unidad comercial (Ventas o Asistencia) o región geográfica (EMEA, APAC). A continuación, esa persona tiene informes directos que se podrían segmentar más, etc. Aunque esto suena muy parecido a un organigrama de RRHH, al modelar el acceso a los datos, céntrese en la accesibilidad de los datos teniendo en cuenta la creación de informes de RRHH.
Las superposiciones siempre son la parte complicada de la jerarquía. Si están en su propia sucursal, requerirán reglas de colaboración, equipos o gestión de territorios para obtener el acceso necesario. Si se pliegan en la jerarquía, puede haber implicaciones de creación de informes.
Es importante emplear el tiempo en configurar la jerarquía de funciones porque es uno de los aspectos fundamentales del modelo de colaboración.
| Casos de uso de jerarquía de funciones |
|---|
| Acceso de gestión: la capacidad de los gestores de ver y hacer lo que sus subordinados puedan ver y hacer. |
| Creación de informes de gestión: la capacidad para la creación de informes de forma jerárquica de modo que cualquier usuario superior de la jerarquía vea más datos que aquellos que están por debajo de ellos. |
| Segregación entre sucursales organizativas: las diferentes unidades comerciales no necesitan ver los datos de otras; tener una jerarquía en la que puede definir sucursales separadas le permite segregar la visibilidad dentro de las unidades comerciales, sin dejar de aumentar la visibilidad hasta los niveles ejecutivos por encima de esas unidades. |
| Segregación dentro de una función: en muchas organizaciones/aplicaciones, las personas que desempeñan la misma función no deben necesariamente ver los datos de los demás. Tener funciones jerárquicas le permite definir un nodo “hoja” en el que todos los datos son esencialmente privados, y seguir acumulando esos datos en una función principal que puede ver todos. |
Grupos públicos
Un grupo público es un conjunto de usuarios individuales, funciones, territorios, etc., que tienen una función en común. Los grupos públicos pueden consistir en:
- Usuarios
- Usuarios del portal de clientes
- Usuarios socios
- Funciones
- Funciones y subordinados internos
- Funciones, subordinados internos y de portal
- Funciones de portal
- Funciones y subordinados del portal
- Territorios
- Territorios y subordinados
- Otros grupos públicos (anidamiento)
Los grupos se pueden anidar (Grupo A anidado en Grupo B), pero no anidan más de cinco niveles. El anidamiento tiene un impacto en el mantenimiento y el rendimiento del grupo debido al cálculo de pertenencia al grupo. Como práctica recomendada, mantenga el número total de grupos públicos para una organización en 100.000.
| Casos de uso de grupos públicos |
|---|
| Cuando necesita proporcionar acceso a un grupo arbitrario de personas, crea un grupo público para recopilarlos y luego utiliza otras herramientas de colaboración para proporcionar al grupo el acceso necesario. La pertenencia a grupos por sí sola no proporciona acceso a los datos. |
| Por lo tanto, los grupos también se pueden anidar uno dentro de otro, permitiendo a un grupo anidado obtener el mismo acceso que el grupo en el que está contenido. Esto permite la creación de jerarquías ad-hoc más pequeñas que no interactúan necesariamente con las jerarquías de funciones o territorios. Si el Grupo A es miembro del Grupo B, los miembros del Grupo A tendrán acceso a los datos compartidos con el Grupo B al mismo nivel de acceso que los miembros del Grupo B. |
| Los grupos también tienen la capacidad de proteger los datos compartidos en el grupo para que no sean accesibles para personas en la jerarquía de funciones por encima de los miembros del grupo. Esto (y tratar con el acceso de propietarios de registros y su jerarquía de gestión) permite la creación de grupos en los que se puede compartir información altamente confidencial: los datos serán accesibles SOLO para miembros del grupo y nadie más en la organización. Esto se logra utilizando el parámetro Otorgar acceso utilizando jerarquías. |
Reglas de colaboración basadas en propietario
Las reglas de colaboración basadas en propietario permiten excepciones a la configuración predeterminada de toda la organización y la jerarquía de funciones que otorgan a los usuarios adicionales acceso a registros que no poseen. Las reglas de colaboración basadas en propietario se basan únicamente en el propietario del registro.
Las reglas de colaboración basadas en propietario de contacto no se aplican a contactos privados o contactos que no están asociados con una cuenta.
El límite de reglas de colaboración en total por objeto es de 300.
| Casos de uso de reglas de colaboración basadas en propietario |
|---|
| Gestión matricial basada en funciones o situaciones de superposición: una persona en Servicio debe poder ver algunos datos de ventas, pero vive en diferentes ramas de la jerarquía, de modo que puede crear una regla que comparte datos entre funciones en diferentes ramas. |
| Para proporcionar acceso a datos a compañeros que tienen la misma función o territorio. |
| Para proporcionar acceso a datos a otras agrupaciones de usuarios (grupos públicos, portal, funciones, territorios). Los miembros de las agrupaciones que poseen los registros se pueden compartir con los miembros de otras agrupaciones. |
Reglas de colaboración basadas en criterios
Las reglas de colaboración basadas en criterios proporcionan acceso a registros basándose en los valores de campo del registro (criterios). Si se cumplen los criterios (uno o varios valores de campo), se crea un registro de colaboración para la regla. La propiedad de registros no es una consideración.
El límite de reglas de colaboración de usuario invitado y basadas en criterios por objeto es 50.
| Caso de uso de regla de colaboración basada en criterios |
|---|
| Para proporcionar acceso a datos a usuarios o grupos basándose en el valor de un campo en el registro. |
Reglas de colaboración de usuario invitado
Una regla de colaboración de usuario invitado es un tipo especial de regla de colaboración basada en criterios utilizada para otorgar acceso a registros a usuarios invitados no autenticados. El límite de reglas de colaboración de usuario invitado y basadas en criterios por objeto es 50.
Atención: El tipo de regla de colaboración de usuario invitado otorga acceso a usuarios invitados sin credenciales de inicio de sesión. Al crear una regla de colaboración de usuario invitado, está permitiendo el acceso inmediato e ilimitado a todos los registros que coincidan con los criterios de la regla de colaboración para cualquier usuario. Para proteger sus datos de Salesforce y proporcionar a sus usuarios invitados acceso a lo que necesitan, considere todos los casos de uso y las implicaciones de la creación de este tipo de regla de colaboración. Implemente controles de seguridad que considere apropiados para la confidencialidad de sus datos. Salesforce no es responsable de ninguna exposición de sus datos a usuarios no autenticados basándose en este cambio desde la configuración predeterminada.
| Caso de uso de regla de colaboración de usuario invitado |
|---|
| Para proporcionar acceso a datos a usuarios invitados no autenticados. |
Compartición manual
A veces es imposible definir un grupo coherente de usuarios que necesitan acceso a un conjunto de registros concreto. Los propietarios de registros u otros usuarios con privilegios adecuados, como administradores del sistema, pueden utilizar la colaboración manual para otorgar permisos de lectura y modificación a usuarios que no tienen acceso de ninguna otra forma. La colaboración manual no está automatizada como la configuración de colaboración de toda la organización, las jerarquías de funciones o las reglas de colaboración. Pero proporciona a los propietarios de registros la flexibilidad de compartir registros con usuarios que deben verlos.
La colaboración manual se elimina cuando cambia el propietario del registro o cuando el acceso de colaboración otorgado no otorga acceso adicional más allá del nivel de acceso predeterminado de colaboración de toda la organización del objeto. Esto también se aplica a colaboraciones manuales creadas de forma programática.
Los registros de colaboración manuales se definen como registros de colaboración con la causa de fila establecida como colaboración manual.
Todos los registros de colaboración (objetos estándar y personalizados) con una causa de fila establecida como Compartir manualmente se pueden modificar y eliminar con el botón Compartir en el formato de página del objeto, incluso si el registro de colaboración se creó de forma programática.
| Caso de uso de colaboración manual |
|---|
| Para proporcionar al usuario la capacidad de otorgar acceso (solo lectura o lectura/escritura) al registro actual a otros usuarios, grupos o funciones. |
Equipos
Un equipo es un grupo de usuarios que trabajan juntos en una cuenta, oportunidad de ventas o caso. Los propietarios de registros pueden crear un equipo para cada registro que poseen. El propietario del registro agrega miembros del equipo y especifica el nivel de acceso que tiene cada miembro del equipo al registro. Algunos miembros del equipo pueden tener acceso de solo lectura, mientras que otros tienen lectura/escritura.
Solo los propietarios, las personas de nivel superior en la jerarquía y los administradores pueden agregar miembros del equipo y proporcionar más acceso al miembro. Un miembro del equipo con acceso de lectura/escritura puede agregar otro miembro que ya tiene acceso al registro con el que está asociado el equipo. El miembro del equipo no puede proporcionarle acceso adicional.
La creación de un miembro del equipo en la aplicación crea dos registros: un registro de equipo y un registro de colaboración asociado. Si crea miembros del equipo de forma programática, debe gestionar tanto el registro del equipo como el registro de colaboración asociado. Solo hay un equipo por registro (Cuenta, Oportunidad o Caso). Si se necesitan varios equipos, dependiendo de sus necesidades específicas, considere la gestión de territorios o la colaboración programática.
| Casos de uso de equipo |
|---|
| Para proporcionar al usuario la capacidad de otorgar acceso (solo lectura o lectura/escritura) a un único grupo de usuarios (el equipo). |
| Si los equipos se gestionan de forma externa, digamos a través de una comisión externa o un sistema de gestión de territorios, la integración se puede utilizar para gestionar el equipo de cuentas. Hay casos en los que la gestión de territorios en un sistema externo puede alinearse con una solución de equipo dentro de Salesforce. |
| El equipo de cuentas puede gestionar varios propietarios de una cuenta. |
| Un único grupo de usuarios (equipo) requiere acceso de solo lectura o lectura/escritura a un registro de oportunidad. (Equipo de oportunidades) |
Jerarquía de territorios
Al utilizar Gestión de territorios de empresa, configura una jerarquía de territorios que muestra la estructura de territorios de un modelo y sirve como su punto de interacción principal. Si Gestión de territorios de empresa está activada, debe gestionar la jerarquía de funciones y la jerarquía de territorios. Para obtener más información, consulte Gestión de territorios de empresa en la Ayuda de Salesforce.
Compartición gestionada Apex
La colaboración gestionada Apex (también conocida como colaboración programática) le permite utilizar código para crear parámetros de colaboración sofisticados y dinámicos cuando un requisito de acceso a datos no se puede cumplir por ningún otro medio.
Si crea un registro de colaboración de forma programática y se utiliza la causa de fila lista para su uso (compartir manualmente), puede mantener este registro de colaboración con el botón Compartir en la aplicación. El registro de colaboración está sujeto a todas las reglas con la causa de fila de colaboración manual, como la eliminación tras la transferencia del propietario.
También puede crear sus propios motivos de colaboración Apex para objetos personalizados para realizar un seguimiento de por qué un registro con un usuario o grupo de usuarios y simplificar la codificación requerida para realizar actualizaciones y eliminaciones de registros de colaboración.
Para obtener más información, revise Compartir un registro utilizando Apex antes de considerar utilizar la colaboración programática.
| Casos de uso de colaboración gestionados por Apex |
|---|
| Ningún otro método de colaboración (declarativo) cumple las necesidades de acceso a los datos. |
| Existe un sistema externo de verdad existente para las asignaciones de acceso de usuarios que continuará dirigiendo el acceso e integrándose con Salesforce. |
| Rendimiento deficiente utilizando componentes de colaboración nativos. (Normalmente se aplica a volúmenes de datos muy grandes) |
| Funcionalidad de equipo en objetos personalizados. |
Reglas de restricción
En su configuración de acceso a datos, es posible que desee evitar que los usuarios vean registros que pueden contener datos confidenciales o simplemente no son esenciales para su trabajo. Puede utilizar reglas de restricción para permitir a los usuarios acceder únicamente a registros que cumplan los criterios que especifique. Cuando se aplica una regla de restricción a un usuario, los registros a los que se otorga acceso al usuario a través de valores predeterminados de toda la organización, reglas de colaboración y otros mecanismos de colaboración se filtran por criterios que especifique. Las reglas de restricción funcionan de la manera opuesta a los componentes de colaboración tratados en este tema; en vez de abrir el acceso a los usuarios, lo restringen aún más.
Las reglas de restricción están disponibles para objetos personalizados, objetos externos, contratos, eventos, tareas, hojas de horas y entradas de hojas de horas. Puede crear hasta dos reglas de restricción activas por objeto en Enterprise Edition y Developer Edition y hasta cinco reglas de restricción activas por objeto en Performance Edition y Unlimited Edition. Las reglas de restricción se aplican a las siguientes funciones de Salesforce:
- Vistas de lista
- Búsquedas
- Listas relacionadas
- Informes
- Buscar
- SOQL
- SOSL
| Casos de uso de reglas de restricción |
|---|
| Desea que algunos usuarios vean solo un conjunto específico de registros. |
| Para simplificar el control del acceso a registros con información confidencial. |
| Para hacer que el acceso a contratos, tareas y eventos sea verdaderamente privado, ya que puede ser difícil de lograr utilizando valores predeterminados de toda la organización. |
Compartición implícita
La colaboración implícita es automática. No puede desactivarlo ni activarlo, es nativo de la aplicación. En otras palabras, la colaboración implícita no es un parámetro configurable; sin embargo, es importante que cualquier arquitecto lo comprenda. La colaboración implícita principal es proporcionar acceso a registros principales (solo cuenta) cuando un usuario tiene acceso a oportunidades secundarias, casos o contactos para esa cuenta. Salesforce tiene una política de acceso a datos que establece si un usuario puede ver un contacto (u oportunidad, caso u pedido), el usuario ve implícitamente la cuenta asociada. La colaboración implícita secundaria es proporcionar acceso a los registros secundarios de una cuenta al propietario de la cuenta. Este acceso se define en la función del propietario en la jerarquía de funciones. La colaboración implícita secundaria solo se aplica a objetos de contacto, oportunidad y caso (secundarios de la cuenta). Los niveles de acceso que se pueden proporcionar son Ver, Modificar y Sin acceso para cada uno de los objetos secundarios cuando se crea la función. Al establecer en Ver, el propietario de la cuenta puede ver implícitamente los registros de objetos asociados (contacto, oportunidad o caso). Al establecer en Modificar, el propietario de la cuenta puede modificar implícitamente el objeto asociado (contacto, oportunidad o caso).
La colaboración implícita no se aplica a objetos personalizados.
No hay un modelo de colaboración que se ajuste a todas las organizaciones de Salesforce. Cada organización tiene diferentes requisitos y retos al intentar diseñar el mejor modelo de colaboración. Es crucial utilizar los componentes de acceso a datos más apropiados para ajustarse a los requisitos de colaboración de la organización. Los siguientes escenarios son retos comunes al intentar diseñar un modelo de colaboración.
| Requisitos o retos | Solución |
|---|---|
| Dos en un cuadro: un gerente de ventas de un área de cobertura geográfica también desea acceder a otra área de cobertura geográfica para ayudar. | Regla de colaboración basada en propietario: Una regla de colaboración basada en propietario funciona aquí porque se trata de casos extremos y no de la norma. También es aceptable si la regla de colaboración basada en propietario proporciona más acceso del realmente necesario porque se trata de un gestor, un individuo de confianza. |
| Los usuarios de operaciones basadas en países necesitan acceso a todos los datos de ventas de países. | Regla de colaboración basada en propietario: Un uso muy común de una regla de colaboración es cuando un departamento diferente (que no sea ventas) necesita acceso a datos de ventas. |
| Al menos el 80% de las veces, hay un equipo “principal 4” en una cuenta (Ejecutivo de cuenta, Representante de ventas interno, Consultor de ventas, Representante de ventas técnico). El sistema de registro para la asignación del equipo de cuentas es externo. Siempre hay un solo equipo en una cuenta. | Equipos: Como siempre hay un solo equipo por cuenta, incluso si hay muchos miembros diferentes con diferentes funciones, la función del equipo de cuentas satisface este requisito. |
| Los gerentes del equipo deben tener el mismo acceso que sus subordinados. | Jerarquía de funciones: La jerarquía de funciones resuelve este requisito permitiendo a los gestores tener acceso a los datos de sus subordinados. |
| El equipo de cuentas asignado no debe ser modificable. | Equipos: Este requisito no se cumple realmente con la función del equipo de cuentas. Sin embargo, tampoco debe evitar que siga utilizando equipos de cuentas. Sin embargo, existen múltiples formas de bloquear los equipos. Para este caso, se utiliza la eliminación del formato de página del equipo de cuentas. |
| Debe haber funciones de “amigo” de modo que cuando alguien está enfermo o de vacaciones, se pueda acceder y cubrir a alguien sin acceso estándar a una cuenta u oportunidad durante el tiempo libre. | Equipos: Un “amigo” puede ser simplemente una función en el equipo que cumple este requisito. Sin embargo, el reto proviene del requisito anterior donde los equipos no deben ser modificables. La única solución es tener un grupo establecido de personas que puedan modificar equipos para crear la función de amigo cuando sea necesario. |
| Cuando una negociación requiere una solución personalizada, las personas adicionales (que no están necesariamente en la organización de ventas) deben tener acceso a la negociación. | Equipos: Un uso bastante estándar del Equipo de oportunidades realizado agregando manualmente un nuevo miembro al Equipo de oportunidades (a través de lista relacionada). También se puede realizar a través de un desencadenador si siempre sabe quién se debe agregar. En este caso, es oportunidad por oportunidad. |
| Requisitos o retos | Solución |
|---|---|
| Dos equipos de oportunidades diferentes de dos unidades comerciales diferentes (Ventas minoristas y Remarketing) necesitan acceso al mismo registro de cuenta. Deben compartir contactos y estar al tanto de todas las actividades en la cuenta. Estas dos unidades comerciales tienen su propia jerarquía y acumulaciones. | Gestión de territorios: La mejor forma de pensar en este requisito es tener dos ramas de una jerarquía que pueden estar estructuradas de forma diferente. Lo que justifica la gestión de territorios es que hay dos niveles de estas dos sucursales diferentes (ambos niveles con miembros = el equipo de oportunidades para esa unidad comercial) que necesitan acceso a la cuenta. Aunque podría haber realizado este requisito con un concepto de equipo, era demasiado granular. La segmentación de ventas no se realizó a nivel de cuenta sino en una jerarquía. |
| Existe un grupo separado de desarrolladores comerciales que están asignados y necesitan acceso a cuentas específicas para un equipo de oportunidades específico (un territorio). Los desarrolladores comerciales son recursos compartidos para los equipos de oportunidades, lo que significa que cada desarrollador comercial puede estar asignado a una o más cuentas para uno o más equipos de oportunidades. | Gestión de territorios: Debido a que este es un grupo de usuarios (o un equipo), y cada equipo de desarrollo comercial podría ser diferente por cuenta, y dado que la gestión de territorios era necesaria por otro motivo, el mejor enfoque es probablemente crear subterritorios o sucursales separadas que representen estos equipos de desarrollo comercial. |
| Existen funciones de asistencia de ventas no basadas en comisiones que necesitan acceso a cuentas de forma puntual. | Equipos: La parte clave del requisito es “puntual”. Esto significa que se realiza cuenta por cuenta de modo que los equipos de cuentas lo proporcionan de forma nativa. |
| El departamento de crédito necesita acceso a todas las cuentas para una unidad comercial concreta. | Regla de colaboración basada en propietario: Esta es una situación en la que, de forma general, para una unidad comercial concreta, un grupo de usuarios debe verlo todo. Este requisito se podría realizar con una regla de colaboración para una función a la que pertenece el grupo, una rama de la jerarquía de funciones a la que pertenece el grupo (función y subordinados) o incluso un grupo público.Gestión de territorios: También puede cumplir este requisito modelando el departamento de crédito como un territorio con la misma lógica para la unidad comercial concreta. |
| Los gestores deben tener el mismo acceso que sus subordinados. | Jerarquía de funciones: La jerarquía de funciones resuelve este requisito permitiendo a los gestores tener acceso a los datos de sus subordinados. |
-
¿Qué sucede con la jerarquía de funciones?
-
No sucede nada en la jerarquía de funciones si también está utilizando una jerarquía de territorios. Sin embargo, si está utilizando previsiones basadas en territorios y previsiones basadas en funciones juntas, debe gestionar dos jerarquías. En este caso, recomendamos que utilice la jerarquía de funciones para modelar la estructura de creación de informes de recursos humanos, luego utilice la jerarquía de territorios para modelar la jerarquía de ventas real. La jerarquía de territorios es la mejor para modelar una estructura de creación de informes matriciales, donde alguien puede reportar a múltiples gerentes.
Si no está utilizando previsiones basadas en territorios y previsiones basadas en funciones juntas, es posible utilizar solo la jerarquía de territorios como la jerarquía de ventas. En este escenario, es mejor simplificar o aplanar la jerarquía lo más posible.
No recomendamos hacer que la jerarquía de funciones y la jerarquía de territorios sean idénticas porque provoca una actividad de colaboración innecesaria.
-
-
¿Puede seguir utilizando equipos?
- -Sí. Sin embargo, si puede satisfacer sus requisitos de acceso dentro de la jerarquía de territorios (como superposiciones), es mejor hacerlo allí que utilizar equipos. Ya está manteniendo múltiples jerarquías (función y territorio), de modo que al intentar simplificar las cosas lo más posible, solo implemente equipos si ningún otro componente de colaboración existente satisface el requisito.
-
Alineación y reasignación
- Hay dos tipos de cambios que se producen: la pertenencia a funciones, equipos o territorios y la estructura de la jerarquía. Los cambios de pertenencia pueden producirse habitualmente a diario, incluso cada hora. Los cambios estructurales de jerarquía (realineaciones) se producen generalmente con menos frecuencia (trimestral, semestral o anual) y pueden ser costosos para los recursos. Lo que se debe tener en cuenta es el volumen de cambios y el número de cambios en cascada que provocará cada cambio. Como regla general, los cambios estructurales no se producen más de trimestralmente y todos los cambios de gran volumen (cambios masivos o masivos) se planifican, prueban y coordinan bien.
-
Grandes volúmenes de datos
-
Si está modelando para la implementación inicial o planificando un cambio de realineación, debe tener en cuenta seriamente el volumen de datos. Existen umbrales donde el rendimiento puede convertirse en un factor, de modo que probar sus cambios en un entorno sandbox es altamente recomendable antes de la producción. Esta prueba también le proporcionará una línea base para el tiempo que tardará el cambio.
Si tiene más de dos millones de cuentas y ha implementado equipos o Gestión de territorios de empresa, debe prestar especial atención al rendimiento. Estos son componentes de modelo de colaboración complejos que pueden generar un gran volumen de registros de colaboración y, por lo tanto, transacciones de larga ejecución.
-
-
Aplazar cálculos de colaboración
- Si tiene un objeto que utiliza la colaboración y tiene un gran volumen de registros (como más de dos millones de cuentas) y debe realizar un cambio masivo (como una realineación trimestral que requiere un cambio de jerarquía), existe una función que el Servicio de atención al cliente de Salesforce puede activar para aplazar los cálculos de colaboración automáticos. De forma nativa, cada cambio individual en la jerarquía de funciones, jerarquía de territorios, grupos, reglas de colaboración, funciones de usuario, pertenencia a equipos o propiedad de registros puede iniciar cálculos de colaboración automáticos. Cuando se realiza un cambio masivo, provoca que comiencen varios nuevos cálculos de colaboración automáticos. Suspendiendo estos nuevos cálculos temporalmente, puede realizar el cambio y luego hacer que los cálculos de colaboración se produzcan todos a la vez. Este método es normalmente más eficiente y tiene un mejor rendimiento para cambios masivos.
-
Sesgos de datos y propiedad
-
Los sesgos de datos se definen como algunos registros principales con muchos registros secundarios. Estos sesgos pueden afectarle mucho cuando algunas cuentas tienen muchos contactos, oportunidades o casos. El índice donde comenzamos a ver la degradación del rendimiento es 1:10.000. Como práctica recomendada, mantenga el índice lo más cerca posible (se prefiere más bajo).
Los sesgos de propiedad son similares a los sesgos de datos, excepto que nos referimos a un único usuario, función o grupo que posee muchos registros para un objeto. Al igual que con los sesgos de datos, estos también pueden causar transacciones de larga ejecución, causando una degradación del rendimiento cuando se produce el cambio. El índice recomendado de propietario con respecto al número de registros también es de 1:10.000.
Si un único usuario posee más de 10.000 registros, como práctica recomendada:
-
El registro de usuario del propietario no debe tener una función en la jerarquía de funciones.
-
Si el registro de usuario del propietario debe tener una función, coloque la función en la parte superior de la jerarquía en su propia rama de la jerarquía de funciones.
-
-
-
Repercusión de jerarquías de cuentas en el acceso a datos
- Muchas personas hacen una mala suposición cuando implementan una jerarquía de cuentas. Suponen que los usuarios que pueden acceder a una cuenta principal también pueden acceder a las cuentas secundarias. El simple hecho de tener solo una relación principal/secundario entre dos registros no dirige el acceso. Aunque la jerarquía de funciones y la jerarquía de territorios funcionan de esta manera, la jerarquía de cuentas no.
Una vez que haya completado su arquitectura de modelo de colaboración, es probable que se enfrente a por qué un usuario puede o no ver un registro. Normalmente, no escuchará cuándo los usuarios pueden ver algo que no deberían, pero si es necesario, hay una forma de ver cada usuario que tiene acceso a un registro y por qué.
El reto más difícil, y probablemente más común, es por qué un usuario no puede ver un registro. Las capas de seguridad que diseñó determinan dónde comienza. Si conoce bien el modelo de colaboración, probablemente sabrá qué componente debería haber proporcionado el acceso y puede comenzar allí. Pero si está menos familiarizado con el modelo de colaboración, comience con la jerarquía de funciones y despegue cada capa para determinar cuál debe proporcionar el acceso. Este es un flujo de solución de problemas.
- Verifique que el usuario tiene permisos para acceder al objeto.
- Identifique la función del usuario que no puede ver el registro y anotarlo.
- Identifique el propietario de la función del registro y anótelo.
- Revise la jerarquía de funciones y verifique que estas dos funciones están en dos ramas diferentes (deben estarlo).
- Ahora debe revisar las reglas de colaboración para el objeto y asegurarse de que no hay ninguna regla que otorgue acceso al usuario. Si es necesario, busque también en grupos públicos. ¿Quizás el usuario quedó fuera de un grupo donde hay una regla de colaboración, o tiene sentido crear una nueva regla de colaboración para otorgar acceso al usuario? Esta opción depende de la arquitectura que está intentando mantener y se aplica tanto a reglas de colaboración basadas en propietario como a reglas de colaboración basadas en criterios.
- Si está utilizando equipos, ¿debería este usuario estar en el equipo para ese registro? ¿Cómo se mantienen los equipos y cómo se produjo la falla?
- Si se utiliza la colaboración manual, el usuario puede haber perdido el acceso porque el propietario del registro cambió. Las colaboraciones manuales se descartan cuando cambia la propiedad. La colaboración manual también podría haberse eliminado utilizando el botón Compartir.
- Si está utilizando Gestión de territorios de empresa, ¿falta el usuario en uno de los territorios? ¿Dónde se mantiene la pertenencia a territorios y cómo se produjo la falta? O bien, tal vez el registro no se asignó al territorio donde el usuario es miembro.
- Si está creando colaboraciones programáticas y existen criterios para crear la colaboración en código, revise el código para comprender por qué se omitió este usuario.