En diciembre, Vantegrate grabó una masterclass de los jueves con un tema que parece simple y no lo es. Seguridad y gobernanza en Salesforce no es un módulo que se prende al final: es el mapa de quién ve qué, desde el día uno.
La clase se filmó el 11 de diciembre y la pueden ver completa en YouTube. Francisco Morales, Josué Mendoza y Adrián (arquitecto invitado, con años de sharing a cuestas) la encararon por conceptos, no por pantallazos.
El equipo de Vantegrate lo dijo de entrada. Configurar una sharing rule lleva diez minutos.
Entender cuándo usar cada herramienta es el trabajo de verdad. Si algo sale mal, no es un ticket liviano: alguien vio un dato que no tenía que ver, y el problema puede ser legal, reputacional o de continuidad.
Por qué la seguridad no es un módulo más
Piensen en una empresa real, no en una org de demo. Cobranza, sueldos, compras y ventas conviven en el mismo sistema, y no todos tienen que ver todo.
Quien trabaja en cobranzas no debería abrir la planilla de sueldos. Quien arma haberes no debería ver lo que cobra un proveedor por una factura.
Eso vale para Salesforce y para cualquier sistema que guarde información. La seguridad acá no es un candado cosmético: es confianza, cumplimiento y continuidad.
El impacto cambia según el dato. No es lo mismo una empresa que vende pan que un banco que guarda información supersensible de sus clientes.
En servicios financieros un empleado con permiso de descarga masiva puede publicar en internet la base entera. Al día siguiente el banco está en todos los diarios.
En salud el dato es igual de delicado. En la clase Juliana planteó un caso concreto: limpieza de datos con un artefacto de un tercero, y la duda de cómo entregarlo sin abrir de más.
También está la transparencia de datos como promesa hacia afuera. Si filtran, la gente deja de confiar, y hay exchanges de cripto que después de una filtración directamente quebraron.
Salesforce le da mucha atención a la seguridad desde siempre. El tipo de cliente (y las normas que exige) empuja a traer el último estándar y a poder demostrarlo.
El modelo agregativo (la sala a oscuras)
Salesforce no piensa la visibilidad como "a quién le apago la luz". La piensa al revés: a quién se la prendo.
Adrián lo llamó modelo agregativo (no sale en una enciclopedia, sale de la práctica). En vez de preguntar quién no puede ver un dato, preguntan quién sí puede.
La analogía de la clase es la que se queda en la cabeza. No arrancan en una sala toda iluminada a la que le van apagando luces: arrancan en una sala totalmente oscura y van prendiendo lucecitas.
Hay una trampa. Si en la primera habitación prendieron una luz, después ya no la pueden apagar (o apagarla duele muchísimo).
Esa es la gobernanza de verdad. Traten de que la base sea lo más restrictiva posible y vayan sumando capitas de acceso, no al revés.
Las capas de visibilidad (de OWD a sharing manual)
Salesforce da tantas herramientas que a veces abruma. El truco es verlas como un mapa, no como un menú de botones sueltos.
Si las usan como piezas aisladas, alguien ve un registro y nadie sabe por qué. Empieza la cacería, y en seguridad esa cacería nunca es un ticket chico.
Organization-Wide Defaults: el piso de la org
El Organization-Wide Default (OWD) es el permiso base de toda la org. Ahí definen si las cuentas las ve todo el mundo, nadie, o un punto intermedio.
La recomendación de la clase fue casi un mantra. Siempre lo más privado posible, y después ir abriendo.
"Private" no es paranoia. Es el único piso que se banca un cambio de negocio sin rehacer todo el edificio.
Roles: el organigrama, no un adorno
Los roles se entienden fácil si los piensan como el organigrama de la empresa. El gerente ve lo de su equipo y el de abajo no ve lo de arriba.
Esa jerarquía corre a nivel registro. Es vertical: visibilidad de arriba hacia abajo, no al revés.
Cuando el negocio no cabe en un organigrama (pasa todo el tiempo), esa capa se queda corta. Ahí entran las reglas horizontales.
Sharing rules, equipos y territorios
Las sharing rules comparten por criterios que no son jerarquía. El caso de libro es un equipo de ventas regional.
El equipo de Buenos Aires ve las cuentas geolocalizadas en Buenos Aires y el de Córdoba ve las de Córdoba. Ya no están subiendo un organigrama: están cortando el mapa en horizontal.
El acceso por equipos es la misma idea: arman un equipo y comparten una cuenta. En Field Service los territorios mueven la visibilidad cuando un trabajo empieza en un lugar y termina en otro.
Para Salesforce esa mezcla (vertical más horizontal) es potencia. También es el punto donde una org grande se vuelve un laberinto si nadie dibujó el mapa entero.
Manual sharing: la excepción de las vacaciones
El manual sharing es el botón de "esta cuenta, esta persona, ahora". Sirve cuando ninguna regla del sistema lo contempló.
El ejemplo de la clase es cotidiano. Adrián es ejecutivo de Córdoba, Francisco está en Buenos Aires, se va de vacaciones y quiere que Adrián tome una cuenta porque al cliente le cayó mejor.
Se la comparte a mano. Es una excepción, no un modelo.
Si viven de excepciones, el modelo está mal. El botón existe para el caso raro, no para sostener la operación.
La historia que duele: público primero, corporativo después
Adrián contó un proyecto grande con dos mundos. Primero se pensó el segmento B2C (venderle a personas físicas).
En un call center el cliente no tiene un ejecutivo fijo. Cualquiera puede atender, así que el OWD de cuentas se puso público: cualquiera las ve.
Anduvo, se desarrolló un montón y pasó el tiempo. Después quisieron sumar clientes corporativos, y esos solo los ve quien los atiende, no toda la org.
El problema es que la luz ya estaba prendida en el primer nivel de todo (la organización). Había que bajar el OWD y reajustar el resto: un retrabajo enorme.
En ese momento no existían las Restriction Rules. Recién ahora hay herramientas para restringir (y son limitadas).
La lección no es sutil: nunca manden Public "porque total no pasa nada". Al primer cambio de negocio, pasa.
Josué tiró un workaround que vale oro. Dejan el OWD en Private y crean una sharing rule del estilo "si el name no es igual a 1, lo ven todos".
Eso se comporta como público. El día que necesitan apagarlo, apagan la sharing rule y el piso sigue privado.
Es un truco. No reemplaza pensar el mapa, pero les deja una palanca para cuando el negocio se dé vuelta.
Perfiles pobres y Permission Sets atómicos
Cuando entran los usuarios concretos, lo primero que aparece es el perfil. Hace años el perfil era la buena práctica y el lugar donde se arrancaba a dar permiso.
Hoy Salesforce empuja al revés. El perfil va lo más mínimo posible (el Minimum Access que aparece en la documentación) y todo lo demás se da con Permission Sets y, sobre todo, Permission Set Groups.
Los Permission Set Groups se sienten como un perfil encubierto. Agrupan Permission Sets atómicos (editar oportunidad, leer oportunidad) y se los asignan al usuario como un combo.
El perfil sigue siendo obligatorio. Todo usuario tiene uno, y ahí viven cosas que todavía no se fueron: la licencia, la app por default, algún permiso básico de campo.
Hay una razón práctica, y duele en cada deploy. El perfil cubre todo (objetos, campos, sistema, apps) y por dependencia se lleva el mundo cuando migran de un sandbox a producción.
Crearon un campo de prueba que no querían llevar, y el perfil dice que ese campo existe, así que también lo tienen que migrar. De esas historias no se salva nadie.
Un Permission Set puede dar permiso a un campo y nada más. Lo migran y listo, sin arrastrar permiso de sistema ni de app.
La buena práctica que salió en la clase es hacerlos atómicos y agruparlos. Si arman un Permission Set por cada funcionalidad y después no los agrupan, el mantenimiento se vuelve un inventario imposible.
Para integraciones entran las Named Credentials. Un Lightning Web Component puede traer datos de otro sistema con un nivel de acceso distinto para el gerente y para quien supervisa.
Si su equipo de Salesforce developers despliega por historias chiquitas, esta distinción no es cosmética. Es la diferencia entre un paquete limpio y un perfil que se lleva basura de prueba.
Restriction Rules: el interruptor que llegó tarde
Durante años el modelo fue solo agregativo. Prendían luces y, una vez prendidas, no las apagaban.
Después llegaron las Restriction Rules. Son reglas para restringir visibilidad cuando ya dieron de más.
La herramienta es simple: eligen un campo y un valor, y ese usuario deja de ver esos registros. El ejemplo de la clase fue ocultar clientes de tipo gobierno.
Si la arquitectura de permisos está bien hecha, no deberían necesitarlas nunca. Salesforce medio que las incentiva a no usarlas.
El mundo no es perfecto. Una empresa empieza con ventas, suma marketing, suma compras, y lo que era una cuenta para uno cambia de significado.
Los permisos cambian porque el negocio cambia. Una Restriction Rule puede salvar esa casuística sin rehacer toda la org.
Ahora, las Restriction Rules tienen restricciones. Casi no se pueden usar en objetos estándar (cuentas, contactos, oportunidades, los que más duelen).
Admiten unos pocos estándar (tareas, eventos, algo de contratos). Se crearon, en la práctica, para objetos custom.
Justo en custom el control de permisos ya era el más fácil. En estándar existe además la seguridad implícita: si ven una cuenta, ven los contactos relacionados, y suelen ver las oportunidades de ese cliente.
No les dieron permiso literal a ese objeto. Se lo heredaron por la relación, y eso explica mil tickets de "por qué este flaco ve esto".
Otro límite duro: máximo dos Restriction Rules por objeto. Piénsenlo bien, porque no hay tercera oportunidad.
Jonathan preguntó por performance (list views, reportes, búsquedas). Adrián fue directo: un modelo complejo (sharing, restriction, permisos heredados, manual sharing) termina generando errores de bloqueo.
Detrás de escena Salesforce crea registros invisibles que enlazan usuario con registro visible. Cuando cambian un atributo, tiene que borrar y recrear esa red.
Si un contacto está relacionado con diez mil usuarios y la visibilidad depende de cinco atributos combinados, una edición chica se vuelve un atasco. La org se traba pensando a quién le da permiso.
La recomendación de Adrián fue cubrir lo más posible con lo básico. Permission Sets y OWD, y poco más, salvo que la casuística lo exija.
Apex sharing (cuando lo declarativo no alcanza)
Casi todo esto es nativo. Llegar a dar permiso por Apex, dijeron, es señal de que algo ya se puso espeso.
La excepción más citada es Field Service. Un trabajo empieza en un lugar y termina en otro, y hay reglas que el modelo clásico no cubre.
Josué recordó un proyecto en agroindustria (Brasil, muchas reglas entre territorios). Al crear un territorio o una cuenta, un Apex gigante borraba los share del día anterior y recalculaba todo.
La magia de Salesforce pasa por ahí: perfiles y roles generan por detrás registros de asignación invisibles. Apex puede crear esas relaciones a mano (los famosos share de Apex).
Es un último recurso, no el camino de todos los días. Si llegan ahí, documenten el Apex share como parte del mapa, no como un parche suelto.
Sharing Hierarchy: el debugger de permisos
Hay un botón que salva proyectos enteros. Se llama Sharing Hierarchy y responde quién ve este registro y por qué.
Antes vivía solo en Classic, escondido en el layout de esa UI. Hoy está en Lightning y sigue medio oculto: hay que agregarlo al layout, no viene por default.
Se paran sobre la cuenta Acme, hacen clic, y ven la lista de usuarios con el tipo de acceso. En "ver más" aparece el motivo: es administrador, es owner, heredó por jerarquía, o tiene un permiso indirecto.
El permiso indirecto es el villano elegante. No le dieron al perfil permiso de ver clientes, y igual los ve porque es dueño de un contacto relacionado.
En Field Service el hilo se pone largo. Francisco veía una cuenta porque era owner de una cita de servicio relacionada a un work order relacionado a esa cuenta.
Esa pantalla les ahorra dos o tres días de análisis. Es el debugging de permisos, y en orgs con grupos públicos, territorios y nubes extra (cada una con su lógica arriba del sharing clásico) no es un lujo: es supervivencia.
Cómo armar la matriz (sin pensar en perfiles primero)
Juliana preguntó lo que todo admin se pregunta en el kickoff. Cómo arman una plantilla de permisos para el cliente, más allá de un Excel de leer / escribir / eliminar.
Francisco y Adrián coincidieron. Todos empezaron con ese Excel de filas (perfil contra objeto), y hoy ya no piensan la solución en ese momento.
Primero documentan perfiles de personas, no de Salesforce. Comerciales, supervisores, directores: quién tiene que ver qué en el idioma del cliente.
Después buscan la herramienta. Un único perfil mínimo, dos Permission Sets, una sharing rule, en el peor caso una Restriction Rule.
Josué lo piensa cada vez más por funcionalidad. Esta función, quién la usa, cuál es el rol de esa persona, y recién ahí: objetos, registros, layouts, Flows.
En orgs grandes esto es trabajo de tiempo completo. Hay arquitectos que solo administran sharing, y no es un capricho: es el costo de crecer sin perder el control.
Si quieren bajar esto a su org (OWD, Permission Sets, el botón de Sharing Hierarchy y un mapa que se pueda explicar), pidan una demo. Se entiende mejor sobre sus objetos que sobre una diapositiva.
Crecer sin perder el control
El desafío de la clase no era "poner candados". Era crecer sin perder el control cuando suman usuarios, funcionalidades, integraciones y equipos.
Eso es casi imposible de adivinar el día uno. Por eso, ante la duda, privado y de a poquito, no abierto "porque total somos pocos".
Los agentes de IA suman otra capa. Agentforce, en lo que se está viendo, entra como proyectos cortos (dos semanas, un mes) arriba de una org que sigue necesitando las mismas cuarenta integraciones y el mismo modelo de permisos.
El agente no reemplaza la gobernanza. La hereda, y si el piso está mal, el agente ve de más o de menos con la misma lógica que un humano.
La clase de diciembre no mostró cada pantalla de Setup. Mostró el mapa: sala oscura, luces que no se apagan, perfiles mínimos y un botón para preguntar por qué un usuario ve un registro.
Eso es gobernanza. El resto es hacer clic.
