Análisis editorial original de OrbTrail ampliado con investigación complementaria, contexto práctico y referencias verificadas.
Salesforce canceló el retiro de los permisos de perfiles, según una nota de soporte publicada el 6 de junio de 2026. Un artículo de Salesforce Ben del 14 de agosto convierte el cambio en una pregunta operativa más útil: si la plataforma ya no obligará a migrar, ¿cómo se distribuye el acceso sin volver a multiplicar perfiles y excepciones por usuario? La respuesta oficial casi no cambia. Salesforce afirma que los perfiles no recibirán nuevas inversiones y recomienda un modelo liderado por permission sets y permission set groups. La cancelación elimina la fecha de fin de vida; no convierte una estructura monolítica en una solución modular.
La distinción importa porque cada usuario sigue asociado a un solo perfil, mientras los permission sets se pueden reutilizar y combinar. Cuando una organización clona perfiles para representar puesto, región, producto y excepción, cada cambio debe repetirse en varias copias. Con conjuntos granulares, una capacidad puede participar en distintos grupos sin duplicar su definición. OrbTrail formula la respuesta central así: el perfil debe ser el punto de partida viable más pequeño; el permission set debe representar una capacidad comprobable; el permission set group debe montar el paquete necesario para una persona o trabajo; y una política debe decidir cuándo esa composición entra y sale de la cuenta del usuario.
El diseño no es simple por naturaleza. Dividir un perfil enorme en decenas de conjuntos mal nombrados solo traslada la confusión. El valor aparece con una taxonomía estable, un propietario por capacidad, criterios observables de concesión y un proceso de revisión. La arquitectura debe responder cuatro preguntas sin investigación manual: qué concede este conjunto, qué grupo lo reutiliza, por qué lo recibió esta persona y cuándo deja de ser necesario. Si alguna respuesta depende de la memoria de un administrador, la organización todavía opera por excepciones, aunque toda la metadata esté en permission sets.
Conserva en el perfil lo que solo él controla
Defaults de app y record type, layouts, horarios y rangos de IP permanecen en la capa obligatoria.
Modela bloques reutilizables
Separa lectura, ejecución y privilegios sensibles para que cada bloque tenga propósito y dueño claros.
Compón el trabajo, no el organigrama
Agrupa capacidades necesarias para tareas; usa muting solo para reducir un conjunto dentro de ese grupo.
Concede, expira y revoca por criterio
Políticas de acceso y expiración convierten cambios de función y privilegios temporales en eventos auditables.
El perfil mínimo es una frontera, no un nuevo perfil universal
La guía de Salesforce separa dos tipos de configuración. El perfil conserva elementos que aún dependen de él: defaults de app y record type, asignación de page layout, login hours y login IP ranges. Los permisos de sistema, objeto y campo, acceso a connected apps, clases Apex, páginas Visualforce, tabs y custom permissions deben pasar a permission sets cuando la plataforma lo permite. Para una implementación nueva, la referencia oficial recomienda comenzar con el Minimum Access Profile. Eso no significa colocar a todos en un perfil sin analizar licencias, experiencias y controles de login; significa evitar que el perfil vuelva a acumular capacidades componibles en otra capa.
Una descomposición útil sigue el trabajo. La publicación How I Solved It de Salesforce propone una capa Base para permisos comunes sin acceso a objetos o campos, una capa Read para navegar y leer una app sin datos sensibles y una capa Persona para lo restante específico del trabajo. No es una norma universal, pero demuestra una propiedad importante: el mismo conjunto Read puede servir a Marketing y Ventas, mientras cada persona recibe solo sus privilegios particulares. Capacidades escasas —publicar Knowledge, aprobar pagos o administrar una integración— pueden mantenerse como conjuntos por tarea sin contaminar a todo el grupo.
Muting reduce un grupo; no revoca acceso concedido por otra vía
Los permission set groups calculan la unión de los conjuntos incluidos. Un muting permission set puede suprimir un permiso dentro de esa composición específica y facilitar la reutilización de un conjunto más amplio entre personas. La frontera es crítica: el mute solo afecta a ese grupo. Si el usuario obtiene el mismo permiso mediante su perfil, otro permission set u otro grupo, sigue siendo efectivo. Muting no debe tratarse como una negación global ni como sustituto para descubrir todas las rutas de concesión. Antes de confiar en él para un campo sensible o Modify All, el equipo debe verificar el acceso combinado del usuario.
Ese comportamiento también cambia la decisión de granularidad. Crear un conjunto gigante y silenciar decenas de elementos en cada grupo produce una matriz difícil de revisar; crear uno por campo produce un inventario imposible de gobernar. El equilibrio es una capacidad cohesiva, con riesgo semejante y ciclo de cambio compartido. Un conjunto Read — Service Console puede reunir app, tabs, objetos y campos no sensibles necesarios para navegar. Exportar informes, ver datos cifrados o ejecutar una acción privilegiada merece bloques separados porque propiedad, aprobación y expiración pueden ser distintas.
La escala real empieza cuando un cambio de puesto también elimina acceso
User Access Policies están disponibles de forma general y pueden conceder o revocar permission sets, permission set groups, licencias de paquete, permission set licenses, grupos públicos y colas. Una política automatizada puede ejecutarse cuando se crea o actualiza un usuario; una política manual puede migrar una población en una operación controlada. Trailhead documenta filtros sobre atributos del usuario, acciones ordenadas y un historial de cambios recientes. Así se puede conectar el acceso con criterios observables —puesto, departamento, estado u otro atributo gobernado— en vez de mantener una lista informal de personas.
La prueba decisiva es un traslado interno. Cuando alguien deja Ventas y pasa a Operaciones, la automatización debe retirar el paquete anterior y conceder el nuevo, no limitarse a acumular acceso. Las concesiones temporales requieren Assignment Expiration en permission sets o groups para que el privilegio termine sin un ticket futuro. En sandbox, el equipo debe simular contratación, promoción, traslado lateral, ausencia y baja; comprobar licencias compatibles; esperar el recálculo de grupos; y validar el acceso efectivo, no solo la presencia de una asignación. Producción debe recibir el mismo guion, propietario y evidencia de rollback.
La cancelación debe terminar la carrera contra el plazo, no el programa de mínimo privilegio
La nota de cancelación recomienda continuar con permission sets, permission set groups, User Access Policies y pruebas en sandbox. Salesforce Well-Architected va más allá: pide conjuntos modulares, grupos alineados con capacidades de negocio, perfiles usados mínimamente y una matriz de seguridad que conecte personas y sistemas con personas. Esto convierte la migración de proyecto técnico en sistema operativo de acceso. Los indicadores útiles pasan a ser cobertura mediante grupos gobernados, asignaciones directas sin justificación, privilegios elevados con y sin expiración, usuarios fuera de la matriz y tiempo para retirar acceso después de un cambio de puesto.
La conclusión de OrbTrail es deliberadamente menos dramática que el anuncio: ninguna organización necesita migrar porque se acerque una fecha de retiro, pero una organización madura debe explicar el acceso de manera reproducible. Empieza con una persona y una capacidad de riesgo, registra el acceso efectivo actual, monta el perfil mínimo y los bloques requeridos, automatiza concesión y revocación, prueba los cinco eventos de ciclo de vida y solo entonces repite. La arquitectura funciona cuando una nueva tarea exige componer un bloque gobernado, no clonar otro perfil ni entregar un permiso a una persona para siempre.
