La forma más confiable de automatizar el aprovisionamiento de usuarios de Salesforce desde Workday o ADP es dejar que el sistema de Recursos Humanos sea la fuente de verdad, pasar las contrataciones, los cambios y las terminaciones por un proveedor de identidad, y hacer que ese proveedor cree, actualice y desactive los usuarios de Salesforce. Salesforce rara vez se conecta directamente al sistema de Recursos Humanos. Casi siempre hay un paso intermedio, y el paso que elija determina cuánto tendrá que mantener.
Este artículo compara las opciones reales, explica qué maneja y qué no maneja cada una, y enumera lo que debe decidir antes de construir nada. Es una guía general. No hemos publicado un conector propio para Workday ni para ADP, y usted debe confirmar los detalles de sus sistemas específicos con cada proveedor.
Qué debe cubrir el "aprovisionamiento"
Automatizar la creación de un usuario es la mitad fácil. Un diseño completo maneja todo el ciclo de vida:
- Ingresos: cree el usuario con la licencia, el perfil o la base de Minimum Access, el rol y los conjuntos de permisos correctos.
- Cambios internos: cuando alguien cambia de equipo o de puesto, cambie su acceso y quite lo que ya no necesita.
- Salidas: desactive en la fecha de terminación e inicie la limpieza de nuestra lista de verificación de baja de usuarios.
- Excepciones: contratistas, voluntarios, recontrataciones, licencias largas y personas con dos roles.
Los cambios internos son donde la mayoría de los proyectos se queda corta. Agregar acceso es sencillo. Quitarlo es lo que mantiene el mínimo privilegio con el tiempo.
Opción 1: Proveedor de identidad con SCIM o un conector nativo de Salesforce
En este patrón, Workday o ADP alimenta a su proveedor de identidad (como Okta o Microsoft Entra ID), y el proveedor aprovisiona Salesforce.
- Cómo funciona: los datos de Recursos Humanos crean o actualizan a la persona en el directorio. La asignación de grupo o rol en el directorio decide quién recibe una cuenta de Salesforce, y el proveedor envía a Salesforce las llamadas de creación, actualización y desactivación.
- Lado de Workday: Microsoft documenta el aprovisionamiento impulsado por Workday hacia Active Directory y Entra ID, donde las contrataciones, los traslados, las terminaciones y las recontrataciones impulsan los cambios de cuenta, con la opción de pasar las terminaciones a otras aplicaciones compatibles. Consulte la guía de Microsoft sobre aprovisionamiento entrante desde Workday.
- Lado de Salesforce: Microsoft también documenta el aprovisionamiento automático a Salesforce desde Entra ID (consultado en noviembre de 2026).
- ADP: ADP tiene sus propias opciones de integración. Revise la documentación actual de ADP para saber cómo se conecta la edición de su producto con su proveedor de identidad, porque no pudimos verificar una única ruta estándar.
Lo que debe saber antes de elegirla:
- Perfil frente a conjuntos de permisos. En el tutorial de Salesforce de Microsoft, la asignación predeterminada envía un solo rol por usuario a un perfil de Salesforce, y solo se admite una asignación de rol por usuario. Los conjuntos y grupos de permisos normalmente necesitan un segundo mecanismo. El sitio de soporte de Okta advierte que los valores de los conjuntos de permisos pueden sobrescribirse cuando se envían actualizaciones de perfil, así que revise con cuidado la asignación de atributos. Consulte la nota de Okta sobre cómo excluir conjuntos de permisos.
- Un usuario de integración dedicado. La guía de Microsoft describe un perfil personalizado para el usuario de integración con API Enabled, Use Any API Auth y Manage Users, y dice que se debe habilitar
login()de la API SOAP, ya que está deshabilitado de forma predeterminada en las orgs creadas en Winter '26 y posteriores. - Una fecha a vigilar. La misma guía dice que la actualización de versión Winter '27 de Salesforce exige el permiso Use Any API Auth para los inicios de sesión de la API SOAP en todas las orgs a partir del 1 de diciembre de 2026. Consulte las notas de la versión de Salesforce para ver los detalles actuales si esto afecta su integración.
- Licencias del lado de identidad. Las funciones de aprovisionamiento que obtiene dependen del plan de su proveedor de identidad, así que confírmelo antes de comprometerse.
- Tiempos de sincronización. Los ciclos de aprovisionamiento son programados, no instantáneos. Pregunte a su proveedor con qué frecuencia se ejecutan y planifique en función de eso las terminaciones del mismo día.
Para una mirada más profunda al estándar, consulte nuestro artículo sobre el aprovisionamiento SCIM para Salesforce.
Opción 2: Inicio de sesión único con aprovisionamiento justo a tiempo
Salesforce permite crear un usuario en el primer inicio de sesión SAML (aprovisionamiento justo a tiempo). Es sencillo y no necesita una sincronización programada.
Funciona para crear usuarios y actualizar atributos al iniciar sesión. Es más débil para las salidas, porque un usuario que nunca vuelve a iniciar sesión nunca se toca, y su cuenta de Salesforce puede seguir activa. Deshabilitarlo en el proveedor de identidad bloquea el inicio de sesión único, pero el usuario de Salesforce puede seguir existiendo, seguir consumiendo una licencia y conservar acceso por otras vías, como los tokens de API. Combine JIT con un proceso de desactivación aparte, o elija la Opción 1.
Opción 3: Middleware o una plataforma de integración
Herramientas como una plataforma iPaaS pueden leer eventos de trabajadores de Workday o ADP y llamar directamente a las API de Salesforce. Es una buena opción cuando:
- No tiene un proveedor de identidad que maneje el aprovisionamiento.
- Necesita lógica de negocio, como asignar grupos de conjuntos de permisos por código de puesto o ubicación.
- Varios sistemas deben actualizarse a partir del mismo evento.
Los costos son la construcción y el mantenimiento. Alguien es responsable de la asignación, del manejo de errores, de las credenciales y del monitoreo. Pregunte a quién se alerta cuando falla la creación del usuario de una nueva contratación.
Opción 4: Flujos de Salesforce con un formulario de solicitud o un archivo
Para organizaciones más pequeñas, un diseño más simple puede funcionar. Recursos Humanos o un gerente envía una solicitud, un flujo crea tareas y un administrador completa la configuración de la cuenta a partir de una plantilla. O una exportación programada del sistema de Recursos Humanos llega a Salesforce, y un flujo la compara con los usuarios actuales y señala las diferencias.
No es automatización completa, pero le da consistencia y un registro. Para algunos equipos es el tamaño correcto. Muchos equipos empiezan aquí y pasan a la Opción 1 a medida que crece su plantilla.
Cómo elegir entre ellas
| Pregunta | Se inclina hacia |
|---|---|
| Ya tiene Okta o Entra ID con aprovisionamiento | Opción 1 |
| Quiere sobre todo un inicio de sesión fácil y tiene pocas salidas | Opción 2, más un proceso de desactivación |
| Reglas complejas, muchos sistemas de destino | Opción 3 |
| Equipo pequeño, pocas contrataciones al mes | Opción 4 |
Qué decidir antes de construir
- Fuente de verdad. ¿Qué sistema es dueño del registro de la persona y qué campos determinan el acceso (departamento, código de puesto, ubicación, gerente)?
- Modelo de acceso. Diseñe primero los grupos de conjuntos de permisos por rol. Sin eso, la automatización solo copia el desorden más rápido. Consulte conjuntos de permisos vs. perfiles.
- Clave de coincidencia. ¿Cómo vincula el registro de Recursos Humanos con el usuario de Salesforce (el Id de empleado, no el correo)?
- Momento de la terminación. ¿El mismo día, y qué pasa con las terminaciones urgentes?
- Licencias. ¿Qué pasa cuando no hay una licencia disponible?
- Evidencia de auditoría. ¿Dónde está el registro de quién fue creado, cambiado y eliminado, y por qué medio?
- Datos de prueba. Use personas claramente ficticias en un sandbox.
Dónde encaja Troppus
Onboard360 de Troppus se describe como automatización del ciclo de vida del usuario basada en Salesforce, con plantillas de aprovisionamiento por rol, asignación automatizada de acceso, eventos del ciclo de vida y una pista de auditoría. Podemos ayudarle a diseñar el modelo de acceso y a decidir cuál de los cuatro patrones se ajusta a sus sistemas.
Preguntas frecuentes
¿Puede Salesforce conectarse directamente a Workday o ADP?
No como un simple interruptor integrado que sirva para todos los casos. La mayoría de las organizaciones se conectan mediante un proveedor de identidad, middleware o una integración personalizada. Confirme las opciones actuales con Salesforce y con su proveedor de Recursos Humanos.
¿Necesito SCIM?
SCIM es un estándar común para aprovisionar y desaprovisionar mediante un proveedor de identidad. Lo necesita, o algo parecido, si quiere que las salidas se desactiven automáticamente.
¿Cómo asigno conjuntos de permisos automáticamente?
Normalmente mediante un segundo paso después de crear la cuenta, como un flujo o una llamada de integración, o mediante su proveedor de identidad si su conector de Salesforce lo permite. Revise con cuidado la asignación para que un sistema no sobrescriba al otro.
¿Qué pasa con las personas que trabajan en varios programas?
Asigne varios grupos de conjuntos de permisos en lugar de crear un rol combinado. Revíselos con regularidad.
¿Cuánto tarda un proyecto como este?
Depende sobre todo de qué tan limpios estén sus roles y su modelo de acceso. Empezar con ese diseño es lo que más tiempo ahorra.
Hable con nosotros sobre su configuración
Si está eligiendo entre estos enfoques, reserve una revisión gratuita de Salesforce. Revisaremos su aprovisionamiento actual, su modelo de acceso y los sistemas involucrados, y le daremos un siguiente paso práctico.