Sharing (visibilidad de registros)
Los permission sets dicen qué puede hacer un usuario con una entidad. El sharing dice qué registros de esa entidad puede ver y editar: ¿un vendedor ve todas las oportunidades o solo las suyas? ¿Su gerente ve las del equipo? Esta página es para quien administra el workspace (configure_entities para el default por entidad; tenant_settings para roles y reglas).
Cómo se decide
Para cada registro, en este orden:
El sharing solo suma acceso: nunca le quita a alguien algo que su permission set le da sobre un registro público. Un usuario con Acceso total a entidades (all_entity_access) saltea toda esta capa.
Org-Wide Default (OWD) por entidad
Es el piso de visibilidad de todos los registros de una entidad. Se elige al crearla y se cambia en Configuración → Constructor de app → Entidades → (entidad) → General.
| OWD | Quién ve | Quién edita |
|---|---|---|
| Public Read/Write | Todos los que pueden leer la entidad | Todos los que pueden editar la entidad |
| Public Read Only | Todos | Solo el dueño, su jerarquía y quien reciba una regla de lectura/escritura |
| Private | Solo el dueño, su jerarquía y quien reciba una regla | Ídem |
El dueño siempre ve y edita lo suyo. Las entidades standard vienen con Cuentas, Contactos y Casos en Public Read/Write, Oportunidades en Public Read Only y Tareas en Private.
En Configuración → Espacio de trabajo → General → Sharing por defecto elegís qué OWD se propone para las entidades nuevas (no afecta a las existentes).
Jerarquía de roles
Los roles (Configuración → Acceso y seguridad → Roles) forman un árbol: cada rol tiene un rol padre. Quien está en un rol ve los registros cuyos dueños están en roles descendientes — hacia abajo, no entre pares: dos vendedores en el mismo rol no se ven entre sí (para eso, una sharing rule).
- Crear un rol: Nuevo role, nombre, slug, rol padre (el selector no deja elegir uno que forme un ciclo).
- Asignar: en el detalle de cada usuario, campo Role. Un usuario tiene como mucho un rol.
- Cambiar el padre de un rol o el rol de un usuario recalcula en segundo plano qué ve cada uno: la pantalla muestra “Recálculo encolado” y tarda de segundos a minutos en aplicarse a los registros existentes. Los registros nuevos lo aplican al instante.
- Un rol con miembros no se puede borrar; se desactiva.
La jerarquía solo importa en entidades Private o Public Read Only; en Public Read/Write todos ven todo igual.
Sharing rules
Excepciones al OWD para compartir registros con un grupo. Se administran en Configuración → Acceso y seguridad → Sharing Rules; cada regla pertenece a una entidad.
| Tipo | Comparte… | Con… | Ejemplo |
|---|---|---|---|
| Por owner | Los registros cuyos dueños están en un rol o permission set (el source) | Los usuarios de un rol o permission set (el target) | “Los casos de Soporte Nivel 1 los ve Soporte Nivel 2” |
| Por criteria | Los registros que cumplen un filtro sobre sus campos | Los usuarios de un rol o permission set | ”Las oportunidades con monto > 100.000 las ve Dirección” |
Cada regla da Solo lectura o Lectura / Escritura, y se puede desactivar sin borrarla.
Crear una: Nueva sharing rule → entidad → tipo → source (solo por owner) → target → nivel de acceso → para por criteria, el filtro con el mismo constructor de condiciones de las list views.
Cómo se aplica:
- A los registros nuevos o editados, al instante.
- A los existentes, en segundo plano al crear, editar o desactivar la regla (“Recálculo encolado”).
- Las reglas solo agregan acceso. Para quitarlo, desactivá o borrá la regla: todo lo que otorgó se revoca.
Casos típicos
| Quiero que… | Configuro |
|---|---|
| Cada vendedor vea solo sus oportunidades y su gerente las del equipo | Oportunidades en Private + roles con la jerarquía del equipo |
| Los de un mismo equipo se vean entre sí | Regla por owner con source = target = el rol del equipo |
| Finanzas vea las oportunidades grandes sin verlas todas | Oportunidades en Private + regla por criteria (monto > X) con target = permission set Finanzas |
| Todos vean las cuentas pero solo el dueño las edite | Cuentas en Public Read Only |
| Un gerente de otra área vea mis registros sin estar arriba mío | Regla por owner de mi rol a su rol |
Qué alcanza y qué no
- Se aplica en listas, detalle, vistas previas, listas relacionadas, reports, la API pública, las notas y los emails del registro, y en lo que hacen automations y componentes (que corren con la identidad del usuario que disparó, salvo que la automation indique otro contexto).
- Pulse tiene su propio modelo por canal y no usa estas reglas.
- La búsqueda global y el historial de campos todavía no filtran por sharing: pueden mostrar un título o un cambio de un registro que después no se puede abrir.
- Un registro que referencia a otro privado muestra el nombre del relacionado aunque no se pueda abrir.
Limitaciones actuales
- No hay reglas que restrinjan (estilo “restriction rules”): solo reglas que comparten.
- Una regla por criteria solo mira campos de su propia entidad, no de relacionadas.
- Si renombrás un campo que usa una regla, la regla queda sin efecto hasta que la edites.
- No hay vista previa del impacto de una regla antes de guardarla, ni un “¿por qué este usuario ve este registro?” en la interfaz.