The most reliable way to automate Salesforce user provisioning from Workday or ADP is to let the HR system be the source of truth, pass hires, changes and terminations through an identity provider, and have that provider create, update and deactivate Salesforce users. Salesforce rarely connects straight to the HR system. There is usually a step in between, and which step you choose decides how much you maintain.
This article compares the real options, explains what each one does and does not handle, and lists what to decide before you build anything. It is general guidance. We have not published a Workday or ADP connector of our own, and you should confirm the details for your specific systems with each vendor.
What "provisioning" has to cover
Automating the creation of a user is the easy half. A complete design handles the whole lifecycle:
- Joiners: create the user with the right license, profile or Minimum Access baseline, role and permission sets.
- Movers: when someone changes team or title, change their access, and remove what they no longer need.
- Leavers: deactivate on the termination date, and start the cleanup in our offboarding checklist.
- Exceptions: contractors, volunteers, rehires, long leave and people with two roles.
Movers are where most projects fall short. Adding access is simple. Removing it is what keeps you least-privilege over time.
Option 1: Identity provider with SCIM or a native Salesforce connector
In this pattern, Workday or ADP feeds your identity provider (such as Okta or Microsoft Entra ID), and the provider provisions Salesforce.
- How it works: HR data creates or updates the person in the directory. Group or role assignment in the directory decides who gets a Salesforce account, and the provider sends create, update and deactivate calls to Salesforce.
- Workday side: Microsoft documents Workday-driven provisioning into Active Directory and Entra ID, with hires, transfers, terminations and rehires driving account changes, and the option to pass terminations on to other supported applications. See Microsoft's Workday inbound provisioning guide.
- Salesforce side: Microsoft also documents automatic provisioning to Salesforce from Entra ID (checked November 2026).
- ADP: ADP has its own integration options. Check ADP's current documentation for how your product edition connects to your identity provider, because we could not verify a single standard path.
Things to know before you choose it:
- Profile versus permission sets. In Microsoft's Salesforce tutorial, the default mapping sends a single role per user to a Salesforce profile, and only one role assignment per user is supported. Permission sets and groups usually need a second mechanism. Okta's support site warns that permission set values can be overwritten when profile updates are pushed, so review the attribute mapping with care. See Okta's note on excluding permission sets.
- A dedicated integration user. Microsoft's guide describes a custom profile for the integration user with API Enabled, Use Any API Auth and Manage Users, and says SOAP API
login()must be enabled, since it is disabled by default for orgs created in Winter '26 and later. - A date to watch. The same guide says Salesforce's Winter '27 release update requires the Use Any API Auth permission for SOAP API sign-ins in all orgs from December 1, 2026. Check Salesforce's release notes for the current details if this affects your integration.
- Licensing on the identity side. Which provisioning features you get depends on your identity provider's plan, so confirm it before committing.
- Sync timing. Provisioning cycles are scheduled, not instant. Ask your provider how often they run, and plan same-day terminations around that.
For a deeper look at the standard itself, see our article on SCIM provisioning for Salesforce.
Option 2: Single sign-on with just-in-time provisioning
Salesforce supports creating a user at the first SAML sign-in (just-in-time provisioning). This is simple and needs no scheduled sync.
It works for creating users and updating attributes at login. It is weaker for leavers, because a user who never signs in again is never touched, so their Salesforce account can stay active. Disabling them in the identity provider blocks single sign-on, but the Salesforce user may still exist, still consume a license, and may still hold access through other paths such as API tokens. Pair JIT with a separate deactivation process, or choose Option 1.
Option 3: Middleware or an integration platform
Tools such as an iPaaS platform can read worker events from Workday or ADP and call Salesforce APIs directly. This is a good fit when:
- You do not have an identity provider that handles provisioning.
- You need business logic, such as assigning permission set groups by job code or location.
- Several systems need updating from the same event.
The costs are build and upkeep. Someone owns the mapping, the error handling, the credentials and the monitoring. Ask who gets alerted when a hire fails to create a user.
Option 4: Salesforce flows with a request form or file
For smaller organizations, a simpler design can work. HR or a manager submits a request, a flow creates tasks, and an admin completes the account setup from a template. Or a scheduled export from the HR system lands in Salesforce, and a flow compares it with current users and flags differences.
This is not full automation, but it gives you consistency and a record. For some teams it is the right size. Many teams start here and move to Option 1 as headcount grows.
Choosing between them
| Question | Leans toward |
|---|---|
| Already have Okta or Entra ID with provisioning | Option 1 |
| Mostly want easy sign-in and few leavers | Option 2, plus a deactivation process |
| Complex rules, many target systems | Option 3 |
| Small team, a few hires a month | Option 4 |
What to decide before you build
- Source of truth. Which system owns the person record, and which fields drive access (department, job code, location, manager)?
- Access model. Design permission set groups per role first. Without that, automation just copies the mess faster. See permission sets vs profiles.
- Matching key. How do you tie the HR record to the Salesforce user (employee Id, not email)?
- Termination timing. Same day, and what happens for urgent terminations?
- Licenses. What happens when no license is available?
- Audit evidence. Where is the log of who was created, changed and removed, and by what?
- Test data. Use clearly fake people in a sandbox.
Where Troppus fits
Troppus's Onboard360 is described as Salesforce-based user lifecycle automation, with role-based provisioning templates, automated access assignment, lifecycle events and an audit trail. We can help you design the access model and decide which of the four patterns suits your systems.
Frequently asked questions
Can Salesforce connect directly to Workday or ADP?
Not as a simple built-in switch that fits every case. Most organizations connect through an identity provider, middleware, or a custom integration. Confirm current options with Salesforce and your HR vendor.
Do I need SCIM?
SCIM is a common standard for provisioning and deprovisioning through an identity provider. You need it, or something like it, if you want leavers deactivated automatically.
How do I assign permission sets automatically?
Typically through a second step after account creation, such as a flow or an integration call, or through your identity provider if its Salesforce connector supports it. Check the mapping carefully so one system does not overwrite the other.
What about people who work for several programs?
Assign several permission set groups rather than creating a combined role. Review them regularly.
How long does a project like this take?
It depends mostly on how clean your roles and access model are. Starting with that design saves the most time.
Talk through your setup with us
If you are choosing between these approaches, book a free Salesforce health check. We will look at your current provisioning, your access model and the systems involved, and give you a practical next step.