Automatic Salesforce User Provisioning

By Andrew Mason

Automated Salesforce User Provisioning with Entra ID

We perform both manual and automated User Access Reviews for IT Teams as one of our services and by far and away the most common audit remediation is that of accounts not being removed or de-activated (de-provisioned) from systems.

This issue more or less goes away with automated provisioning / de-provisioning.

I’ve previously written an article around Saving costs with SCIM ([link here]) and one of the examples I gave was Salesforce.

I chose Salesforce for a couple of reasons:

  1. It’s pretty common in the enterprise.
  2. Salesforce licenses are priced such that efficient allocation is important.
  3. I’ve done this a few times before.

We recently were asked by a client to confirm that they could auto-provision users from Microsoft Entra to Salesforce. They were considering migrating to Salesforce.

Together we had spent considerable time and effort to ensure that auto-provisioning worked across the board for every single application.

They were resolute in ensuring each and every application would preserve this functionality.

I’d done this at least 3 times prior, however the client had been clear they wanted a recording they could take to their board given their recent focus.

Microsoft and (in theory) Salesforce makes this easy with a gallery application in Entra, so in my mind this was a 15 minute job… I was wrong.

Fast forward over and week and here we are! As it turns out, Salesforce had at some stage in the past changed the default configuration of it’s new instances and now the auto-provisioning no longer worked “Out the box”. Furthermore, every document of the process (Salesforce, Microsoft, Youtube video and your chosen search engine) glossed over key components of the setup.

If you just want this to work and are not interested in the implementation, [Contact Us] (/contact/) and we can enable this for your Salesforce Org. Likewise if you’re using another IDP (Okta, Ping Identity, Auth0, Keycloak etc..) the process will be slightly different. We can help.

Video

Salesforce Automatic User Provisioning

I used a Winter ‘26 developer edition for testing. It does work with the Developer instances.

Advice to ignore

The following advice you will find on the internet at large is patently incorrect.

This is common advice on the internet. This is not true.

What is correct, is that if you are trying to use the Salesforce SCIM API directly, you can’t use this with Entra ID. This is due to a current limitation on Custom Complex schema types. Salesforce uses complex schema types for Entitlements and Entra doesn’t support this. I’ve seen and tried many work arounds for this but I’ve not been able to get this working.

It’s not clear that this offers any advantage, as Microsoft (or Salesforce) has done the hard work for you within the Gallery Application. As far as I can tell, there is no reason not to use the gallery app.

You need an Identity Enabled Salesforce Developer instance.

When I spoke to the very helpful Salesforce team, they were aware that this seemed to be a thing, however no one I spoke to at Salesforce was able to tell me if this was just an artefact of the past or how one would go about provising and instance.

Either way, it’s not required - I’ll demo this.

You need an Enterprise or Professional instance of Salesforce

Also false.

You need a ‘Connected Application’, ‘External Client’ etc..

This will likely be the default / required in the Summer ‘27 edition of Salesforce.

However as of today, this doesn’t work with Entra ID.

Pre-requisites

Entra ID

This will work with any instance of Entra ID, however automatic provisioning based on Entra Groups only works with P1/P2 Licensed Entra tenants.

Assigning individual users works fine but obviously is more challenging in an Enterprise setting. It’s unlikely any Enterprise using Salesforce doesn’t have a least a P1 tenant.

The user creating the integration MUST be assigned at least the Cloud Application Administrator role.

Both the Application Administrator and Global Administrator roles will work also as they are broader roles.

The Entra admin center at the time of writing is https://entra.microsoft.com

Salesforce

Any instance should work. I’ve tested with the Enterprise and Free Developer instances.

However, for this to work, Salesforce does need specific System and User configurations.

You MUST have a user with

a. A valid license b. A profile with enough permissions. By default the existing ‘System Administrator’ profile will work.

IMPORTANT

For production use cases you should create a dedicated profile that has only the required permissions via Permission Sets. It’s outside the scope of this article to go too far into the Salesforce setup but it’s much easier to configure a minimal permission set when you have an implementation that you know is working on the Entra ID side.

High Level Steps

We need to do the following in this order.

Salesforce

  1. Create a dedicated Provisioning User
  2. Acquire the provisioning user’s Security Token
  3. Enable the SOAP API <- The un-documented magic

Entra

  1. Create a dedicated Salesforce group.
  2. Register a Salesforce Enterprise Application in Entra ID
  3. Create a new user to provision in Entra ID
  4. Allocate the new user to the group
  5. Login with the new user.

Detailed Implementation

The remainder of this article walks through the exact configuration required to make automated provisioning work reliably between Entra ID and Salesforce. This is the material I will also demonstrate in the accompanying video.

Salesforce Configuration

1. Create a Dedicated Provisioning User

The provisioning user is the identity Entra ID will use to create, update, and deactivate users in Salesforce. It must be a real Salesforce user with:

  • A valid Salesforce license
  • A profile with API access
  • Permission to manage users

In most cases, the built‑in System Administrator profile will work for initial testing. For production, create a dedicated profile and assign only the required permissions via Permission Sets. This ensures the provisioning identity is tightly scoped and auditable.

Once the user is created, log in as that user at least once to ensure the account is active and the password is set.

2. Acquire the Security Token

Salesforce requires a Security Token when authenticating via API from an untrusted network. This token is appended to the user’s password when the gallery connector authenticates.

To obtain it:

  • Log in as the provisioning user.

  • Navigate to Settings → My Personal Information → Reset My Security Token.

  • Salesforce will email the token to the user.

This token is required later when configuring the Gallery Application in Entra ID.

3. Enable the SOAP API login() Toggle

There is one Salesforce configuration that is commonly missed and causes the integration to fail: SOAP API login must be enabled for the provisioning user’s profile.

To enable it:

  • In Salesforce go to Home → User Interface → User Interface

  • Locate Enable SOAP API login() and enable it

Some new orgs or developer instances appear to reject provisioning attempts even when credentials and tokens are correct. Enable this setting for the provisioning user’s profile and the gallery connector will be able to authenticate and perform SCIM operations. Entra ID Configuration

4. Create a Dedicated Salesforce Group

Provisioning should always be driven by group membership. This ensures:

  • Clear separation of duties
  • Predictable lifecycle behaviour
  • Easy auditability
  • No reliance on manual user assignment

Create a new group in Entra ID, for example:

Salesforce – Licensed Users

This group will be used to trigger provisioning.

5. Register the Salesforce Enterprise Application

In Entra ID:

  • Go to Enterprise Applications.
  • Search for Salesforce.
  • Select the Salesforce gallery application.
  • Add it to your tenant.

This application contains Microsoft’s pre‑built SCIM configuration for Salesforce. There is no need for a custom app registration or a custom SCIM connector.

Once created, open the application and navigate to:

Provisioning → Get Started

Set the mode to Automatic.

You will be prompted for:

  • Tenant URL (Salesforce instance URL)
  • Username (provisioning user)
  • Password (provisioning user password)
  • Secret Token (Salesforce Security Token)

Enter those values and save.

6. Create a Test User in Entra ID

Create a new user specifically for validation. This ensures you can observe the full lifecycle:

  • Create
  • Update
  • Deactivate

Assign the user a UPN and attributes that match your organisation’s naming standards.

7. Add the User to the Salesforce Group

Add the test user to the group created earlier.

This is the event that will trigger provisioning once the integration is active.

8. Log in as the New User

Once provisioning completes, the user should be able to log in to Salesforce using Entra ID SSO. This validates:

  • The user was created
  • The user was assigned a license
  • The user was assigned a profile
  • The user can authenticate via SAML/OIDC

If any of these fail, the provisioning logs in Entra ID and the User Provisioning Requests in Salesforce will show the cause. Connecting Entra ID to Salesforce (practical)

The Entra ID Gallery Application is the supported, repeatable path for Salesforce provisioning. You do not need to generate an OAuth Bearer token manually. The gallery app expects the following values and will handle the SCIM interactions for you:

  • Username — the provisioning user’s username.
  • Password — the provisioning user’s password.
  • Secret Token — the Salesforce Security Token for the provisioning user (the token Salesforce emails when you reset it).

Enter those four values into the Gallery Application’s Provisioning configuration and click Test Connection. If the test succeeds, Entra will use the gallery app’s built‑in SCIM connector to create, update and deactivate users in Salesforce. You do not need to perform any additional OAuth token exchange outside of what the gallery app performs for you.

Validating the End‑to‑End Flow

To demonstrate the full lifecycle for audit and board evidence:

  1. Add a test user to the Entra group used for Salesforce provisioning.
  2. Trigger or wait for the provisioning cycle.
  3. Confirm the user appears in Salesforce with the expected license and profile.
  4. Update an attribute in Entra and confirm it syncs to Salesforce.
  5. Remove the user from the group and confirm the user is deactivated in Salesforce.

Capture screenshots or logs at each step for audit trails. The Entra provisioning logs and Salesforce User Provisioning Requests provide the necessary evidence for compliance reviews.