El sharing (compartir) permite otorgar acceso a registros específicos fuera de lo que los roles permiten. Es la herramienta para excepciones y colaboración ad-hoc, pero debe usarse con cuidado.
Objetivos de aprendizaje
- Entender cuándo y cómo usar el sharing de registros
- Diferenciar entre sharing manual y automático
- Conocer el impacto en rendimiento del sharing excesivo
- Implementar Access Teams como alternativa escalable
Cuando los roles no son suficientes
El modelo de seguridad basado en roles y unidades de negocio cubre la mayoría de escenarios, pero inevitablemente aparecen excepciones. María es vendedora en España y normalmente solo ve oportunidades españolas, pero necesita colaborar con Juan de México en un proyecto especial que involucra un cliente multinacional.
¿Cómo resuelves esto? Podrías cambiar el rol de María para darle acceso a nivel Organization, pero eso le daría acceso a TODAS las oportunidades, no solo a la que necesita. Podrías mover a María a una BU diferente, pero eso cambiaría todo su acceso, no solo para esta oportunidad.
Aquí es donde entra el sharing. Juan puede "compartir" esa oportunidad específica con María, dándole acceso temporal y limitado sin alterar nada del modelo de seguridad general.
Cómo funciona el sharing
Cuando compartes un registro con alguien, estás creando una excepción a las reglas normales de seguridad. El sistema registra: "María tiene acceso a la Oportunidad X con permisos Y, aunque sus roles no se lo darían".
Lo interesante es que puedes ser granular con los permisos. No es "acceso o no acceso". Puedes especificar exactamente qué puede hacer la persona con el registro compartido:
- Read: Puede ver el registro
- Write: Puede modificarlo
- Delete: Puede eliminarlo
- Append: Puede asociar otros registros a este
- AppendTo: Puede asociar este registro a otros
- Assign: Puede reasignarlo a otra persona
- Share: Puede compartirlo con otros (re-sharing)
Normalmente, cuando compartes algo, das Read y quizás Write. Dar Delete o Assign a alguien a través de sharing es inusual y debería pensarse cuidadosamente.
El privilegio Share
Para poder compartir registros, el usuario necesita el privilegio Share en la entidad correspondiente. Y el nivel de ese privilegio determina qué puede compartir:
- Share a nivel User: Solo puede compartir sus propios registros
- Share a nivel BU: Puede compartir cualquier registro de su unidad de negocio
- Share a nivel Organization: Puede compartir cualquier registro del sistema
Es importante ser cuidadoso con quién tiene el privilegio Share, especialmente a niveles altos. Alguien con Share a nivel Organization puede dar acceso a registros sensibles que normalmente estarían protegidos.
Sharing manual vs automático
Sharing manual
El sharing manual es cuando un usuario conscientemente decide compartir un registro con alguien. Lo hace a través de la interfaz de Dynamics 365: abre el registro, va a la opción "Share", selecciona usuarios o equipos, y configura los permisos.
Es intuitivo y funciona bien para excepciones genuinas: "necesito que Pedro vea esta oportunidad específica para la reunión de mañana".
Sharing automático
El sharing también puede automatizarse mediante plugins de Dataverse, flujos de Power Automate, o incluso acciones SDK. Algunos escenarios comunes:
"Cuando una oportunidad supera $100k, compártela automáticamente con el director comercial." Esto se implementa con un flujo que dispara cuando el campo de monto cambia y ejecuta la acción GrantAccess.
"Cuando un caso se escala, compártelo con el equipo de especialistas." Similar: un flujo detecta el cambio de estado y comparte el registro.
El sharing automático es poderoso, pero hay que ser cuidadoso de no crear reglas que generen demasiados shares. Cada share tiene un costo de rendimiento que veremos a continuación.
El impacto en rendimiento: la tabla POA
Esta es la parte que mucha gente no conoce hasta que les causa problemas. Cuando compartes un registro, Dataverse crea una entrada en una tabla del sistema llamada PrincipalObjectAccess (POA). Esta tabla almacena todas las relaciones de sharing: qué usuario/equipo tiene qué permisos en qué registro.
Cada vez que alguien accede a un registro, el sistema consulta la tabla POA para verificar si hay shares aplicables. Si la tabla POA tiene millones de registros, estas consultas se vuelven lentas. El rendimiento de todo el sistema puede degradarse.
He visto organizaciones donde la tabla POA tenía 50 millones de registros porque alguien implementó un plugin que compartía cada nuevo registro con 20 equipos. El sistema se volvió inutilizablemente lento y la solución requirió limpiar la tabla POA, lo cual es un proceso delicado.
Mejores prácticas para evitar problemas
Comparte con equipos, no con usuarios individuales. Si necesitas dar acceso a 10 personas, es mejor crear un equipo con esas 10 personas y compartir el registro con el equipo (1 entrada en POA) que compartir con cada persona individualmente (10 entradas en POA).
Revoca shares cuando ya no sean necesarios. El proyecto terminó, la colaboración acabó, pero los shares siguen ahí ocupando espacio en POA. Implementa un proceso para limpiar shares obsoletos.
No uses sharing para acceso regular. Si te encuentras compartiendo sistemáticamente el mismo tipo de registros con las mismas personas, eso es una señal de que tu modelo de seguridad necesita ajustes. Probablemente deberías modificar roles o reorganizar unidades de negocio en lugar de parchar con sharing.
Considera Access Teams. Como vimos en el módulo anterior, los Access Teams son una alternativa más escalable al sharing manual para colaboración ad-hoc. En lugar de compartir un registro con 5 personas individualmente, defines un Access Team para el registro y añades las 5 personas al equipo.
Revocando shares
El sharing puede revocarse de varias formas:
Manualmente: El propietario del registro o un administrador abre las opciones de Share y elimina usuarios o equipos de la lista.
Automáticamente: Un flujo o plugin puede ejecutar la acción RevokeAccess cuando cambia alguna condición. Por ejemplo, cuando un proyecto pasa a estado "Completado", revocar todos los shares.
Al reasignar: Dependiendo de la configuración, reasignar un registro puede mantener o revocar los shares existentes. Esto es configurable.
Puntos clave
- El sharing es para excepciones a las reglas normales, no para acceso regular
- Requiere el privilegio Share en la entidad correspondiente
- Puedes especificar permisos granulares: Read, Write, Delete, etc.
- Los shares se almacenan en la tabla POA - evita que crezca demasiado
- Comparte con equipos en lugar de usuarios individuales para mejor rendimiento
- Considera Access Teams como alternativa más escalable