El modelo de colaboración de Salesforce es un elemento esencial en la capacidad de su organización para proporcionar acceso seguro a datos de aplicaciones. 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 arquitectos y administradores del sistema avanzados. 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 diseñado: 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 de datos móviles

La seguridad a nivel de registro le permite proporcionar 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 compartir grupos 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 rápidamente acceso 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 la seguridad a nivel de campo puede configurarse 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 elementos constructivos 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.

Colas y propiedad de registros

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 nivel superior en una jerarquía (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 de mayor jerarquía de funciones pueden acceder a colas desde vistas de lista y tomar la propiedad de registros en una cola.

Si un solo usuario posee más de 10.000 registros, como mejor práctica:

• 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 bifurcación 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 los usuarios tienen 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 vuelta a Privada). Sin embargo, estos cambios requieren un nuevo cálculo de colaboración y dependiendo del volumen podrían dar como resultado tiempos de procesamiento largos.

Solo para objetos personalizados, puede configurar el parámetro Otorgar acceso utilizando jerarquías. Si no se selecciona (el valor predeterminado está seleccionado), 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 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 hacer contacto con el Servicio de atención al cliente de Salesforce para aumentar este límite. Como mejor práctica, mantenga el número de funciones internas en 25.000 y el número de funciones externas en 100.000.

Como mejor práctica, mantenga la jerarquía de funciones en no más de 10 niveles de ramas en la jerarquía.

Cuando cambia la función de un usuario, se evalúan las reglas de colaboración relevantes para corregir el acceso según sea necesario. Los colegas con 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. Esto se crea habitualmente a partir de la comprensión del ámbito de un gestor, comenzando desde la parte superior. El CEO supervisa toda la compañía. El CEO suele tener reportes directos que luego se pueden segmentar por Unidad de negocio (Ventas o Asistencia) o región geográfica (EMEA, APAC). A continuación, esa persona tiene reportes 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 reportes de RRHH.

Las superposiciones son siempre 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 reportes.

Es importante emplear el tiempo en configurar la jerarquía de funciones porque es uno de los aspectos fundamentales del modelo de colaboración.

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 constar de:

• 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 (anidación)

Los grupos se pueden anidar (Grupo A anidado en Grupo B), pero no anidan más de cinco niveles. La anidación tiene un impacto en el mantenimiento y el desempeño del grupo debido al cálculo de la pertenencia al grupo. Como mejor práctica, mantenga el número total de grupos públicos para una organización en 100.000.

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 son de su propiedad. 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 contactos 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.

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 de 50.

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 de registro a usuarios invitados no autenticados. El límite de reglas de colaboración de usuario invitado y basadas en criterios por objeto es de 50.

Advertencia: 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.

Compartir manualmente

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 colaboración manual 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.

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 de su propiedad. 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 mayor 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 el registro del equipo y 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

Jerarquía de territorios

Al utilizar Gestión de territorios de compañía, 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 territorio de compañía 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 compañía en la Ayuda de Salesforce.

Compartición gestionada Apex

La colaboración gestionada por 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 cualquier 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 la 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 del motivo de 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.

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 el usuario tiene acceso 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 forma opuesta a los componentes de colaboración tratados en este tema; en vez de abrir el acceso a 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
• Reportes
• Buscar
• SOQL
• SOSL

Compartición implícita

La colaboración implícita es automática. No puede desactivarla ni activarla, es nativa de la aplicación. En otras palabras, la colaboración implícita no es una configuración configurable; sin embargo, es importante para cualquier arquitecto comprenderla. La colaboración implícita principal proporciona 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 indica 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 proporciona 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.

• ¿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 pronósticos basados en territorios y pronósticos basados en funciones conjuntamente, debe gestionar dos jerarquías. En este caso, recomendamos que utilice la jerarquía de funciones para modelar la estructura de creación de reportes de RRHH, 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 reportes matriciales, donde alguien puede reportar a múltiples gestores.

    Si no está utilizando pronósticos basados en territorios y pronósticos basados en funciones juntos, 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 tanto como sea posible.

    No recomendamos que la jerarquía de funciones y la jerarquía de territorios sean idénticas porque causan 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 mantener las cosas lo más sencillas posible, solo implemente equipos si ningún otro componente de colaboración existente satisface el requisito.

• Alineación y reasignación

  • Existen 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) suelen producirse 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, haga que los cambios estructurales no se produzcan más de trimestralmente y que todos los cambios de gran volumen (cambios masivos o masivos) estén bien planificados, probados y coordinados.

• 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 desempeño puede convertirse en un factor, de modo que probar sus cambios en un entorno sandbox es muy 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 implementó equipos o Gestión de territorios de compañía, debe prestar especial atención al desempeño. 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 duració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 realicen todos a la vez. Este método es normalmente más eficiente y tiene un mejor desempeño 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 perjudicarle mucho cuando algunas cuentas tienen muchos contactos, oportunidades o casos. El índice donde comenzamos a ver la degradación del desempeño es 1:10.000. Como mejor práctica, 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 varios registros para un objeto. Al igual que con el sesgo de datos, estos también pueden causar transacciones de larga ejecución, causando una degradación del desempeño cuando se produce el cambio. El índice recomendado de propietario a número de registros es también 1:10.000.

    Si un solo usuario posee más de 10.000 registros, como mejor práctica:

    • 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 bifurcación de la jerarquía de funciones.

• Impacto de jerarquías de cuentas en el acceso a datos

  • Muchas personas asumen 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 este modo, la jerarquía de cuentas no.

Una vez haya completado su arquitectura de modelo de colaboración, probablemente se le planteará el reto de 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.

1. Verifique que el usuario tiene permisos para acceder al objeto.
2. Identifique la función del usuario que no puede ver el registro y anote.
3. Identifique el propietario de la función del registro y anótelo.
4. Revise la jerarquía de funciones y verifique que estas dos funciones están en dos ramas diferentes (deben estarlo).
5. 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 a reglas de colaboración basadas en propietario y reglas de colaboración basadas en criterios.
6. 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 el fallo?
7. 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 se podría haber eliminado utilizando el botón Compartir.
8. Si está utilizando Gestión de territorios de compañía, ¿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, quizás el registro no se asignó al territorio donde el usuario es miembro.
9. 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.