Por qué un modelo de uso compartido correcto a posteriori es más difícil que uno bien construido desde el inicio
El problema típico no se revela en el primer mes. Se manifiesta cuando un gerente de ventas regional nota que está viendo una oportunidad de un territorio competidor, o cuando un agente de servicio abre el caso de un cliente VIP que solo debería ser visible para un equipo dedicado. Ambos casos son el resultado directo de un orden de trabajo inverso: se definen objetos y campos, y solo al final se pregunta quién debería ver qué.
El modelo de visibilidad en Salesforce se construye con capas que funcionan en conjunto y no de forma aislada: Los Organization-Wide Defaults (OWD) establecen la línea base más restrictiva, la Role Hierarchy añade acceso vertical según la estructura de gestión, los Sharing Rules abren acceso horizontal según un criterio de negocio, los Teams y el Manual Sharing abordan casos específicos, y el Apex Managed Sharing interviene cuando la lógica es demasiado compleja para expresarse de forma estática. Este orden es crucial: cualquier capa elegida prematuramente genera una deuda difícil de deshacer, ya que los permisos ya otorgados se perciben como un derecho existente.
El mapa de capas y cuándo elegir cada una
| Capa | Qué problema resuelve | Cuándo elegirla | Riesgo de una elección incorrecta |
|---|---|---|---|
| OWD | Línea base: quién no puede ver nada por defecto | Siempre se configura, generalmente "Private" para objetos sensibles | Un OWD demasiado abierto hace que cualquier otra capa sea redundante |
| Role Hierarchy | Acceso vertical de un gerente a la información de sus subordinados | Cuando la estructura de gestión también refleja la necesidad de supervisar datos | Una jerarquía "política" que no se corresponde con la propiedad real de los datos |
| Sharing Rules | Apertura de acceso horizontal según un criterio fijo (rol, grupo, valor de campo) | Un equipo interjerárquico que necesita acceso al mismo tipo de registro | Multitud de reglas superpuestas que dificultan saber quién abrió qué |
| Public Groups | Agrupación de usuarios para compartir, sin relación con la jerarquía | Cuando un grupo de trabajo no corresponde a un único rol organizacional | Grupos que no se actualizan cuando un empleado cambia de rol |
| Account/Case Teams | Acceso variable a un solo registro según la composición de su equipo | Cuando cada cliente o caso tiene un equipo único y cambiante | Mantenimiento manual que se olvida cuando el equipo cambia |
| Territory Management | Asignación de acceso basada en reglas dinámicas y multidimensionales | Asignación variable según varios atributos simultáneamente, acceso concurrente para varios representantes | Complejidad de mantenimiento que no se justifica por debajo de un cierto umbral organizacional |
| Apex Managed Sharing | Uso compartido derivado de una lógica dinámica que no puede expresarse en una regla estática | Criterio que depende de un cálculo, un evento externo o una combinación de campos | Código sin monitoreo que sigue ejecutándose después de que el requerimiento comercial ha cambiado |
OWD: La decisión que determina todas las demás
OWD no es solo una configuración de seguridad técnica, es una declaración organizacional sobre quién es el propietario inicial de la información. La regla práctica: establezca el OWD según la condición más restrictiva que realmente se necesite, y desde ahí abra el acceso mediante Sharing Rules y no al revés. La razón es que la ampliación puntual del acceso es sencilla y está documentada, mientras que la restricción de un acceso ya existente requiere comunicación organizacional, porque los usuarios perciben la pérdida de acceso como un perjuicio, incluso si es una corrección de un error histórico.
Un punto al que no siempre se le presta suficiente atención: el OWD se establece por separado para cada objeto, y los objetos dependientes (Master-Detail) heredan la visibilidad del objeto principal. Al construir un nuevo modelo de datos, se debe verificar la cadena de dependencia completa antes de establecer el OWD; de lo contrario, un objeto "secundario" definido como "Public" por error podría exponer información del objeto principal.
Role Hierarchy vs. la estructura gerencial real
El error más común es replicar el organigrama en la Role Hierarchy tal cual, sin verificar si también refleja el flujo de propiedad de los datos. Un gerente regional necesita ver las oportunidades de su equipo; esa es una función gerencial. Pero un director financiero no necesita ver automáticamente todos los casos de servicio solo porque está más arriba en la jerarquía general; si existe tal necesidad, se resuelve con una Sharing Rule específica y no con una jerarquía excesivamente amplia.
Una jerarquía de uso compartido separada de la jerarquía de informes organizacional es una solución legítima y, a veces, preferible, especialmente en organizaciones con una estructura matricial donde el informe gerencial no coincide con la propiedad de los datos del cliente.
Mapa de decisión: qué mecanismo de uso compartido activa cada situación
- La necesidad cambia según un rol fijo y predecible → Role Hierarchy.
- La necesidad es compartida por un grupo de trabajo que cruza roles → Public Group + Sharing Rule.
- La necesidad cambia según la composición del equipo en un registro individual → Account Team o Case Team.
- La necesidad depende de una combinación de condiciones dinámicas (geografía, producto, tamaño de cliente) → Territory Management.
- La necesidad se deriva de un cálculo, un evento externo o una condición que no puede expresarse con una regla estática → Apex Managed Sharing.
- La necesidad es una excepción puntual y temporal para un registro individual → Manual Sharing, con supervisión y documentación.
Esta matriz debe escribirse antes de trabajar con las herramientas, no en paralelo, de lo contrario, elegiremos un mecanismo según lo que sea familiar para el equipo de desarrollo y no según lo que se ajuste a la necesidad.
Escenario de ejemplo: Un fabricante de equipos industriales con tres canales de venta
Supongamos un fabricante de equipos industriales hipotético con aproximadamente 180 usuarios de Salesforce, que opera en tres canales: venta directa por zona geográfica, venta a través de distribuidores y venta a cuentas estratégicas globales gestionadas simultáneamente por varios representantes en diferentes países.
Un intento inicial de utilizar solo la Role Hierarchy fracasó: una cuenta estratégica global no pertenecía a una única jerarquía regional, y un representante en Alemania no veía las actualizaciones de su colega en Brasil sobre la misma cuenta. La solución elegida combinó tres capas: el OWD en Account y Opportunity se estableció como "Private"; la Role Hierarchy se utilizó para el acceso gerencial regular dentro de cada región; y para las cuentas estratégicas se configuró un Account Team dinámico que se actualiza automáticamente mediante Flow cuando cambia el campo "Strategic Account Owner Region". Los distribuidores obtuvieron acceso separado a través de una Sharing Rule basada en un Public Group dedicado, para que no estuvieran expuestos a las cuentas de venta directa.
El resultado: el tiempo de cálculo de Sharing Recalculation se mantuvo estable, ya que la mayor parte del acceso se derivó de una estructura fija (Role, Public Group) y solo una minoría de las cuentas –las estratégicas– dependía de una actualización dinámica. La principal lección: no es necesario un único mecanismo "correcto" para toda la organización; es preciso adaptar el mecanismo al tipo de dependencia de cada subgrupo de registros. Una ampliación sobre la elección de patrones de integración y un modelo de datos compatible se encuentra en la guía de arquitectura de CRM.
Riesgos específicos en la planificación de la visibilidad y acciones preventivas
| Riesgo | Cómo se manifiesta en la práctica | Acción preventiva |
|---|---|---|
| OWD abierto "temporalmente" en la fase piloto | La apertura permanece incluso después de que el sistema pasa a producción | Establecer de antemano una fecha de cierre y documentarla como un elemento de Go-Live, no como una recomendación |
| Multiplicidad de Sharing Rules superpuestas | Imposibilidad de saber con certeza por qué un usuario ve un registro determinado | Un nombre estándar para cada regla que incluya la razón comercial, y una revisión periódica de las reglas no utilizadas |
| Apex Sharing sin pruebas de rendimiento bajo carga | El cálculo del uso compartido se retrasa con el crecimiento del volumen de datos | Realizar una prueba de carga en Sharing Recalculation antes de duplicar el volumen de registros en producción |
| Jerarquía de uso compartido replicada de una jerarquía organizacional política | Los gerentes ven datos para los que no tienen una necesidad comercial | Separar la jerarquía de Roles para fines de uso compartido de la jerarquía de informes oficial cuando no sean idénticas |
| Manual Sharing que se acumula sin un propietario | Los permisos excepcionales permanecen después de que la razón para compartir ya no es relevante | Un proceso de caducidad (Expiration) o una revisión trimestral de los casos de uso compartido manual |
| Cambio de rol de usuario sin actualizar los grupos públicos | El acceso antiguo permanece abierto y falta el nuevo acceso | Integrar la actualización de grupos y roles como un único paso en el proceso de cambio de estado de un empleado |
Lista de verificación antes de finalizar el modelo de uso compartido
- ☐ El OWD se configuró según la condición más restrictiva requerida, no según la conveniencia de la fase de desarrollo.
- ☐ La cadena de dependencia entre objetos Master-Detail fue verificada frente al OWD del objeto principal.
- ☐ La Role Hierarchy fue verificada frente a la propiedad real de los datos, no solo frente al organigrama.
- ☐ Cada Sharing Rule tiene un motivo comercial documentado y un propietario responsable de su validez.
- ☐ Se verificó si el Territory Management es realmente necesario o si representa una complejidad innecesaria.
- ☐ El código de Apex Sharing se probó bajo un volumen de datos realista, no solo en un entorno de pruebas (sandbox) pequeño.
- ☐ Existe un proceso para actualizar grupos públicos y permisos al cambiar de rol o al finalizar el contrato de un empleado.
- ☐ Se definió una frecuencia de revisión periódica para el Manual Sharing y para las Sharing Rules inactivas.
- ☐ Se examinó el impacto del modelo de uso compartido en el rendimiento de los informes y las ejecuciones de lotes (batches) grandes.
- ☐ Existe un plan de respuesta en caso de que se detecte una exposición excesiva en producción.
¿Cómo saber si el modelo resiste la carga?
Una primera medida es el tiempo de recalcular el uso compartido (Sharing Recalculation) después de un cambio estructural; un aumento constante a lo largo del tiempo indica que el modelo se está acercando a una complejidad no planificada. Una segunda medida es el número de solicitudes de soporte del tipo "me falta acceso" frente a "tengo acceso redundante"; una proporción que se inclina bruscamente hacia un lado indica que el OWD o las Sharing Rules no están bien calibradas. Una tercera medida, especialmente importante en organizaciones con múltiples sistemas, es la correspondencia entre los permisos de Salesforce y los permisos en los sistemas sincronizados, especialmente cuando se trata de una arquitectura de integración basada en eventos, como se describe en la Guía de Arquitectura Dirigida por Eventos en Salesforce.
En las organizaciones que operan varios "Org", la cuestión del modelo de uso compartido a menudo se mezcla con la pregunta de si realmente se necesita más de un entorno de producción; el debate completo al respecto aparece en Salesforce Single Org vs. Multi Org, y en la elección de un patrón de integración compatible en la Guía de Patrones de Integración de Salesforce.
Resumen
Un buen modelo de uso compartido y visibilidad no se mide el día del lanzamiento; se mide cuando la organización crece, cuando un usuario cambia de rol y cuando alguien pregunta: "¿Por qué no veo esto?". La forma de lograrlo no es elegir una herramienta y aplicarla a todo, sino mapear cada grupo de registros según su tipo de dependencia (fija, horizontal, dinámica o excepcional) y elegir el mecanismo adecuado para cada uno. Un OWD restringido por defecto, una Role Hierarchy que refleje la propiedad real, Sharing Rules con un motivo documentado y Apex Sharing solo cuando la lógica lo justifique, es la combinación que funciona incluso cuando la organización duplica su volumen y complejidad.