Your Entra-to-Salesforce provisioning breaks on December 1. One permission fixes it

Entra ID creates and switches off Salesforce users by signing in as one Salesforce account, with a password, through an old Salesforce API. From December 1 that sign-in fails unless the account holds one more permission. It takes minutes to add. Do it this month, test it, and then start thinking about Summer '27, when Salesforce retires that API.

The error is easy to fix. The trouble is everything that quietly stops while it's there. Entra's provisioning job is what switches off a leaver's Salesforce account, and once its sign-in fails, nobody's account gets switched off. Someone who can still log in to Salesforce directly with a password keeps your customer data at their fingertips. Even when they can't, the licence is still assigned to them and the account turns up as active in the next access review.

It also fails quietly. Microsoft's own tutorial warns that Salesforce Login History can show successful sign-ins for the integration account while Entra's Test Connection still fails. So the Salesforce admin looks, sees green, and closes the ticket. Behind Entra's "credentials are invalid" message, the underlying error is INSUFFICIENT_ACCESS.

Entra doesn't keep trying forever, either. When credentials stop working, the provisioning service puts the app in quarantinedefinitionWhat Entra does with a provisioning job that keeps failing. It runs less and less often, and after four weeks it's switched off., cuts its runs back to once a day, and disables the job altogether after about four weeks. A failure on December 1 that nobody spots turns into a switched-off provisioning job around the end of December or early January, and switching it back on with Restart provisioning means a full initial cycle.

For engineers: the Entra gallery connector for Salesforce and Salesforce Sandbox authenticates through SOAP API logindefinitionAn old Salesforce sign-in call that takes a username and a password (often with a security token) and hands back a session. Salesforce is retiring it.() with the Admin Username, Admin Password and Secret Token fields. Salesforce says login() doesn't exist from API 65.0 on, and the older versions lose it in Summer '27. So whichever version the connector calls, its way in has an end date. That's why this post has two deadlines, one urgent and one coming later.

Only the first item has to be done this month, and for most tenants it's a few minutes in Salesforce Setup. The second matters if your Salesforce org is newer, or if someone has already switched login() off to get ahead of the retirement. In either case, Entra's connection fails today, December or no December.

The idle check is the one people tend to miss. Production provisioning runs all day, so it keeps login() alive. A sandbox that's wired to Entra but hasn't synced since spring is a different story. If nothing in that sandbox has called login() in six months, Salesforce turns it off on December 15, and the next time someone tests a provisioning change there, it fails for reasons that have nothing to do with their change.

There are really only two choices for December, and one of them is a trap. The third choice, getting off SOAP login() altogether, isn't yours to make for the gallery connector. Salesforce says to move custom code to External Client Apps with OAuth, using the JWT bearer or client credentials flow for server-to-server work. For a vendor's connector, its advice is to ask the vendor for a version that supports that.

Microsoft's tutorial asks for an account with Manage Users, and Manage Users switches on a long list of other admin permissions. The account was already powerful. Use Any API Auth doesn't change that much. What it does do is make this account visible again, because you're touching it, and that's a good moment to check who knows its password and where the token is kept.

Entra may not be the only thing still signing in this way. Data loaders, older middleware and scheduled scripts can do it too, and they all hit the same wall on December 1. Salesforce points at two places to look, and you won't need new tools for either.

This change is small, but it points at a weak spot. A powerful Salesforce account signs in with a password and a token that only change when someone remembers. When the password is reset, Salesforce issues a new token, and provisioning breaks until someone pastes it into Entra. The fixes below make that account easier to see and harder to lose track of.

The three companies below are made up. Each one is a setup you could easily find in a tenant that provisions Salesforce from Entra, so use them as a checklist for your own.

We go app by app through your Entra tenant and user by user through Login History, and make the permission and token changes with your Salesforce admins. Each integration account ends up in your access reviews with an owner, and you get a written plan for Summer '27. The Microsoft Entra ID page and Salesforce page cover the wider work. You can bring in identity engineers for the clean-up, or ask for an assessment if you'd rather someone looked first.