User Provisioning for Connected Apps
User Provisioning for Connected Apps in Salesforce is a feature that automates the creation, update, and deactivation of user accounts in third-party applications that have been wired into Salesforce as Connected Apps.
Definition
User Provisioning for Connected Apps in Salesforce is a feature that automates the creation, update, and deactivation of user accounts in third-party applications that have been wired into Salesforce as Connected Apps. The Salesforce org acts as the identity authority, and lifecycle events (a new hire is provisioned, a role changes, an employee leaves) push directly to the target application without manual account management on the receiving end.
The feature uses the standard SCIM 2.0 protocol where the third party supports it, and falls back to a custom Apex-based connector where it does not. Salesforce ships a User Provisioning wizard inside the Connected App configuration that maps Salesforce user attributes (name, email, role, manager, custom fields) to the receiving application's user schema and defines which Salesforce events trigger which provisioning actions.
How User Provisioning for Connected Apps actually moves user data between systems
How the provisioning loop runs
User Provisioning sits between two systems. Salesforce holds the authoritative user list (the source of truth) and the connected third-party application holds the target user list. The platform watches the Salesforce User object for relevant changes: new user activation, attribute updates, role changes, and deactivation. When a watched event fires, the User Provisioning engine builds a SCIM payload (or an Apex callout payload for non-SCIM targets), authenticates against the target system using OAuth credentials stored on the Connected App, and pushes the change. The target system returns a result that the platform writes to the User Provisioning Log so admins can see what synced and what failed.
SCIM versus custom Apex connector
SCIM (System for Cross-domain Identity Management) is the open standard for identity provisioning, and most modern SaaS applications (Slack, Box, Workday, ServiceNow, Atlassian, Zoom) support it. When the target application supports SCIM 2.0, User Provisioning uses the built-in SCIM connector and the configuration is wizard-driven. When the target does not support SCIM, you write a custom Apex class that implements the User Provisioning interface (the UserProvisioning.Plugin abstract class). The Apex class translates the Salesforce-side event into whatever API call the target understands. The wizard hides this complexity; advanced setups expose it through the Connected App provisioning configuration page.
Attribute mapping and the user schema
Each provisioning configuration includes a User Attribute Mapping section that maps fields from the Salesforce User record to fields on the target system user object. Standard mappings include Username, Email, FirstName, LastName, Title, Department, Manager, and IsActive. Most orgs add custom mappings for things like cost center, employee id, office location, and the role group the target system uses for access control. The mapping is one-way (Salesforce to target), so any field that the target system needs but Salesforce does not store has to be derived from a Salesforce expression or a default value. Test the mapping thoroughly against a sandbox before turning on production sync, since wrong mappings can lock real users out of real systems.
Event triggers and the change stream
User Provisioning supports four event triggers: user creation, user update, user deactivation, and user reactivation. Each event is configurable independently, so you can choose to push only deactivations (and provision new users manually) or push everything. The platform uses an asynchronous queue for the actual API call, so the source-side User update transaction does not wait for the target system to respond. This is important for performance: if Slack is down, the Salesforce admin does not see a 30-second hang when activating a user. The queue retries failed calls with exponential backoff, and after a configurable number of retries, the failure surfaces in the User Provisioning Log for manual investigation.
Permission Set Groups and the access-on-provision pattern
Most orgs pair User Provisioning with Permission Set Groups so that activating a user in Salesforce both creates the target-system account and assigns the right access at the target. The pattern is: a Permission Set Group represents a role (Sales Manager, Customer Support Tier 2, Finance Analyst). When a user is assigned to the group in Salesforce, the User Provisioning attribute mapping passes the group name to the target system, which uses it to assign the target-system equivalent role. This avoids the access-management drift where users have a Salesforce role but the target system still treats them as a baseline user. Pair User Provisioning with HR-driven group assignment for true joiner-mover-leaver automation.
User Provisioning Log, troubleshooting, and audit
The User Provisioning Log is a custom object inside Salesforce that records every provisioning event, the target system response, the attribute payload, and the result code. Open Setup, User Provisioning Requests, to see the log in the UI. Common failure modes include attribute mapping mismatches (Salesforce passes a value the target rejects), OAuth token expiration (re-authorize the Connected App), target-system rate limiting (back off and retry), and unsupported user schema changes (target system added a required field that Salesforce does not map). Each failure logs the full request payload, so debugging is concrete rather than guesswork. Build a dashboard on the log object filtered to failures so admins see issues without manually checking each user.
Standing up User Provisioning for a third-party Connected App
Setting up User Provisioning is a six-piece configuration: enable the Connected App, pick the protocol (SCIM or custom Apex), configure OAuth credentials for the target system, build the user attribute mapping, choose the event triggers, and verify with a small pilot group. Each piece is independent of the others, but they have to be wired up in the right order or the first provisioning attempt fails silently. The pilot group is the most important step: never roll out User Provisioning to all users in one shot.
- Configure the Connected App and OAuth for the target system
Open Setup, App Manager, and find or create the Connected App that represents the target system. In the Connected App configuration, enable OAuth Settings, choose the right OAuth scopes (api, refresh_token, openid usually), and generate the Consumer Key and Consumer Secret. Configure the OAuth callback URL with the target system administrator. On the target side, register Salesforce as an OAuth client with the Consumer Key and Secret. Authorize the Connected App once as an admin user with the right target-system permissions, since the resulting refresh token is what User Provisioning uses for all subsequent calls.
- Pick the provisioning protocol and configure the connector
In the Connected App User Provisioning section, click Configure User Provisioning. The wizard asks whether the target system supports SCIM. If yes, enter the SCIM endpoint URL and select the connector. If no, click Create Custom Connector and supply the Apex class that implements the UserProvisioning.Plugin interface. The Apex class has to be written by a developer and deployed to the org separately; the wizard only references it. Configure the protocol-specific options (SCIM version, custom Apex parameter values) and save before moving to attribute mapping.
- Build the user attribute mapping
The attribute mapping wizard shows the target system user schema (loaded automatically over SCIM, or manually defined for custom Apex). Map each required target field to a Salesforce User attribute or a Salesforce expression. Common mappings: target Username from Salesforce Username; target FirstName from Salesforce FirstName; target Email from Salesforce Email; target Department from Salesforce Department; target Role from Salesforce Permission Set Group. Mark each mapping as required or optional based on the target system rules. Test the mapping by selecting a test user and clicking Preview, which shows the actual SCIM payload Salesforce will send.
- Enable triggers, pilot, and roll out
In the wizard final step, choose which events trigger provisioning (Create User, Update User, Deactivate User, Reactivate User). Most orgs enable all four. Save the configuration. Run a pilot by assigning a small group of test users to the Connected App profile or permission set and confirming the target system receives the provisioning calls. Watch the User Provisioning Log for the pilot group for 48 hours, then expand to the full population once you are confident. Never enable for all users on day one; bad mappings discovered mid-rollout are expensive to clean up.
- OAuth refresh tokens expire if not used for the configured token lifetime. When they expire, every provisioning call fails until an admin re-authorizes the Connected App. Monitor token age on a quarterly cadence.
- Attribute mapping is one-way (Salesforce to target). Changes on the target side do not flow back. If users edit profile fields on the target system, they get overwritten on the next Salesforce update.
- User Provisioning is asynchronous. A user activated in Salesforce may not appear in the target system for several minutes. Set expectations with the help desk so they do not file false bugs about missing accounts.
- Permission Set Group changes do not always fire the User Update event automatically. Confirm in sandbox that role changes propagate the way you expect before relying on them for downstream access management.
- Bad mappings can lock real users out of real systems. Always pilot with a small group before rolling out, and always test the deactivation path in sandbox before enabling in production.
Trust & references
Straight from the source - Salesforce's reference material on User Provisioning for Connected Apps.
- Configure User Provisioning for Connected AppsSalesforce Help
- User Provisioning Apex Plug-inSalesforce Developer Docs
- Connected Apps OverviewSalesforce Help
Hands-on resources to go deeper on User Provisioning for Connected Apps.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is User Provisioning for Connected Apps?
Q2. What does it automate?
Q3. Why is it valuable?
Discussion
Loading discussion…