Salesforce SCIM es una forma estándar de que un sistema de identidad, como Okta o Microsoft Entra ID, cree, actualice y desactive usuarios de Salesforce automáticamente. En lugar de que un administrador capture a cada nueva contratación y recuerde apagar a cada persona que se va, lo hace su directorio impulsado por Recursos Humanos. Elimina mucho trabajo manual, pero no decide qué se le permite ver a una persona. Esa parte todavía hay que diseñarla.
Esta guía explica qué es SCIM, qué admite Salesforce, cómo se conectan los proveedores de identidad más comunes y los errores que vigilaríamos. Todo lo relativo a Salesforce y a los proveedores de identidad que aparecen abajo se verificó con la documentación de los proveedores en noviembre de 2026.
Qué es SCIM, en lenguaje sencillo
SCIM significa System for Cross-domain Identity Management. Es un estándar abierto para pasar registros de usuarios entre sistemas. Un sistema guarda la fuente de verdad sobre las personas (su directorio). Otro sistema (Salesforce) recibe a esas personas como cuentas de usuario.
La propia documentación de Salesforce dice que admite el aprovisionamiento y la administración de usuarios mediante SCIM, con extensiones a la especificación SCIM 2.0 para poder administrar propiedades de usuario específicas de Salesforce. Usted envía operaciones de creación, lectura, actualización y deshabilitación a los puntos finales de SCIM, y cada solicitud necesita un token de acceso OAuth 2.0 (Salesforce Help, SCIM overview, consultado en noviembre de 2026).
Qué hace SCIM por un administrador de Salesforce
Cuando el aprovisionamiento está bien configurado, el ciclo de vida se ve así:
- Ingreso: se agrega a una persona al grupo correcto de su directorio y se crea un usuario de Salesforce para ella.
- Cambio interno: su puesto, departamento o gerente cambia en el directorio y se actualiza el registro de Salesforce.
- Salida: se la elimina o deshabilita en el directorio y su usuario de Salesforce se desactiva.
Ese último paso es el que más importa. Las cuentas olvidadas son uno de los hallazgos más comunes en una revisión de acceso, y un exempleado con un inicio de sesión que funciona es un riesgo real para cualquier organización que tenga datos de clientes o donantes.
Salesforce nunca elimina a un usuario. Lo desactiva. La documentación de Salesforce establece que los objetos de usuario se desactivan en lugar de eliminarse, lo cual mantiene intacto el historial y permite reactivar al usuario más adelante (Salesforce Help, SCIM overview, consultado en noviembre de 2026).
Qué no hace SCIM
SCIM mueve identidades. No es un diseño de acceso. Tres cosas que no resuelve por sí solo:
- No decide qué puede hacer la persona. Un usuario nuevo todavía necesita un perfil y los conjuntos de permisos correctos. Si asigna a todos a un solo perfil amplio, habrá automatizado el exceso de permisos. Nuestra guía de conjuntos de permisos vs. perfiles explica cómo estructurarlo.
- No limpia el acceso existente. Si quien se va ya tenía conjuntos de permisos o uso compartido adicionales, la desactivación detiene el inicio de sesión, pero el diseño de fondo puede seguir desordenado.
- No reemplaza el inicio de sesión único. El aprovisionamiento crea la cuenta. El SSO decide cómo inicia sesión la persona. Funcionan bien juntos, pero se configuran por separado.
Cómo se conectan los proveedores de identidad más comunes
No todos los conectores usan SCIM de la misma manera, así que conviene leer la documentación de su herramienta específica.
Okta. La integración de Okta con Salesforce admite enviar usuarios nuevos, enviar actualizaciones de perfil, enviar la desactivación de usuarios, importar usuarios nuevos y actualizaciones de perfil desde Salesforce, y reactivar usuarios (Okta Help, Salesforce supported features, consultado en noviembre de 2026). Okta también señala que los cambios de perfil hechos del lado de la aplicación se sobrescriben con los valores de Okta, así que decida desde el principio qué sistema es dueño de cada atributo (Okta Help, provisioning, consultado en noviembre de 2026).
Microsoft Entra ID. Microsoft documenta el aprovisionamiento y desaprovisionamiento automáticos de Entra ID a Salesforce. Su tutorial describe la conexión con la API de aprovisionamiento de usuarios de Salesforce, y tiene algunos detalles que conviene conocer (Microsoft Learn, Salesforce provisioning tutorial, consultado en noviembre de 2026):
- Necesita un usuario de integración dedicado con un perfil personalizado que tenga API Enabled, Use Any API Auth y Manage Users.
- Inicia sesión mediante la llamada
login()de la API SOAP. Microsoft señala que Salesforce deshabilita esa llamada de forma predeterminada en las orgs creadas en Winter '26 y posteriores, y que una actualización de versión Winter '27 exige el permiso Use Any API Auth para los inicios de sesión SOAP en todas las orgs a partir del 1 de diciembre de 2026. - Entra importa los perfiles de Salesforce y los muestra como roles de aplicación. Cada usuario necesita un rol válido asignado, y la asignación predeterminada admite un rol por usuario.
- No se puede configurar en una cuenta de prueba de Salesforce.
La conclusión: no suponga que una sola guía de configuración sirve para todas las herramientas. Confirme qué llama realmente su proveedor en Salesforce y qué necesita que se le permita hacer.
Quién debería usarlo y quién puede esperar
El aprovisionamiento de tipo SCIM da resultado cuando usted tiene:
- Un directorio central en el que ya confía (Okta, Entra ID o similar).
- Ingresos y salidas frecuentes, como personal de temporada, voluntarios con inicio de sesión o contratistas.
- Una expectativa de cumplimiento o de los financiadores de que el acceso se quite con prontitud.
- Más que un puñado de usuarios de Salesforce, de modo que los pasos manuales se omiten fácilmente.
Si tiene un equipo pequeño, no tiene un directorio central y hay pocos cambios, una lista de verificación de baja por escrito puede bastar por ahora. Nuestra lista de verificación para dar de baja usuarios en Salesforce es un buen punto de partida, y sigue aplicando cuando automatice.
Si un proveedor de identidad es más de lo que necesita, hay otro camino: automatizar el ciclo de vida del usuario dentro de Salesforce. Onboard360 de Troppus es un producto basado en Salesforce para eso, con plantillas de aprovisionamiento por rol, asignación automatizada de acceso, eventos del ciclo de vida (nueva contratación, cambio de rol, licencia, terminación) y una pista de auditoría. Cuál ruta le conviene depende de lo que ya tenga.
Un despliegue seguro en seis pasos
- Haga un inventario. Liste los usuarios activos actuales y con quién se relacionan en su directorio. Aquí aparecen los huérfanos y los duplicados.
- Defina primero los roles. Decida qué perfil y qué conjuntos de permisos recibe cada tipo de puesto antes de automatizar nada.
- Cree un usuario de integración dedicado. Dele solo los permisos que documenta el conector. No reutilice el inicio de sesión de administrador de una persona.
- Pruebe en un sandbox. Ejecute casos de ingreso, cambio interno y salida con usuarios ficticios antes de tocar producción.
- Empiece con un grupo piloto. Asigne un grupo pequeño, observe los registros de aprovisionamiento y luego amplíe.
- Revise de forma programada. Busque sincronizaciones fallidas, límites de licencias y usuarios que existen en Salesforce pero no en el directorio.
Problemas comunes que debe esperar
- Límites de licencias. Si no quedan licencias, la creación falla. Microsoft lo enumera como un error conocido.
- Nombres de usuario duplicados. Los nombres de usuario de Salesforce deben ser únicos en todas las orgs de Salesforce, de modo que un nombre de usuario puede chocar con uno de otra org.
- Campos obligatorios faltantes. Los usuarios a los que les faltan atributos como el correo o el alias no se podrán crear.
- Aprobaciones manuales por correo. Microsoft señala que Salesforce exige que los cambios de correo se aprueben antes de que surtan efecto, por lo que puede ver entradas de actualización repetidas hasta que eso ocurra.
- Credenciales que expiran. Una contraseña o un token restablecido en el usuario de integración puede romper la sincronización sin avisar.
Preguntas frecuentes
¿SCIM viene incluido con Salesforce?
La documentación de Salesforce dice que la compatibilidad con SCIM está disponible en Salesforce Classic y Lightning Experience en todas las ediciones (Salesforce Help, SCIM overview, consultado en noviembre de 2026). El lado del proveedor de identidad suele ser una suscripción aparte, y las funciones de aprovisionamiento que obtiene dependen del plan de ese proveedor.
¿SCIM elimina usuarios de Salesforce?
No. Salesforce desactiva a los usuarios en lugar de eliminarlos. El registro permanece, de modo que los informes y el historial que hacen referencia al usuario siguen funcionando.
¿SCIM asigna conjuntos de permisos?
Depende del conector y de cómo esté configurado. En el tutorial de Entra, la asignación predeterminada asigna un perfil por usuario. Pruebe la asignación de conjuntos de permisos en un sandbox antes de suponer que está cubierta.
¿SCIM es lo mismo que el inicio de sesión único?
No. SCIM administra la existencia y los atributos de la cuenta. El inicio de sesión único administra cómo inicia sesión la persona. Muchos equipos usan ambos.
¿Seguimos necesitando revisiones de acceso si automatizamos?
Sí. La automatización mantiene las cuentas en sincronía con su directorio. No le dice si el acceso en sí es apropiado. Consulte nuestra guía para encontrar usuarios con exceso de permisos en Salesforce.
¿Quiere una segunda opinión sobre el ciclo de vida de sus usuarios?
Si está evaluando el aprovisionamiento con un proveedor de identidad, la automatización dentro de Salesforce o una mejor lista de verificación, podemos revisar cómo se crean y se quitan hoy los usuarios en su org y decirle dónde están las brechas. Reserve una revisión gratuita de Salesforce.