Salesforce | Provisioning reset does not clear past connections?

Chris Csanyi 41 Reputation points

I thought I understood the mappings for Provisioning but getting stuck. I got it all working great for over a year but need to setup up some people to basic Chatter Free users type. Inside of Salesforce, I thought if I deactived the users account changed the username which is what I am matching on, removed the Federrated ID from the Salesforce user object it would start fresh with a new users using the Chatter Free user type and login with new role but keeps matching to the old users Salesforce ID but not clear how it is matching and how can I clear out to start this users over again. I have restarted and I thought cleared the provisioning but keeps matching to old SalesforceIDs.

What can I do to free the linkage between the two? Trying to understand what I am missing from the setup.

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,604 questions
0 comments No comments
{count} votes

Accepted answer
  1. AmanpreetSingh-MSFT 56,506 Reputation points

    @Chris Csanyi At the initial provisioning, we match userPrincipalName (AAD) to Username (Salesforce). We then establish a link based on the ID value – specifically, it’s linking the primary key from the source directory of AAD (aka the sourceAnchor) with the primary key from the target directory of Salesforce (aka the targetAnchor). Once that link is established, it will persist across any attribute changes except to the primary keys themselves.

    Now to break this link, we need to use below graph call to clear state and restart provisioning. Clicking “Clear state and restart” from the Azure AD portal doesn't pass resetScope value as Full and doesn't break this link.

    Go to and sign-in with Global Admin account by clicking on the "Sign in to Graph Explorer" button on the left.

       "criteria": {  
           "resetScope": "Full"  

    Note: In the above call, {id} needs to be replaced with Object ID of the Salesforce Enterprise App and {jobId} with synchronization job id that you will find under provisioning blade as highlighted below:


    This will start initial sync cycle and if UPN (AAD) to Username (SF) match is not already there, it will create a new user in Salesforce.


    Please do not forget to "Accept the answer" wherever the information provided helps you to help others in the community.

3 additional answers

Sort by: Most helpful
  1. AmanpreetSingh-MSFT 56,506 Reputation points

    @Chris Csanyi Please change other user attributes in Salesforce that should be unique, like email, alias etc. for which you have configured mapping in Azure AD Provisioning blade.

    Once done try to Clear the state and start provisioning again.


    Please do not forget to "Accept the answer" wherever the information provided helps you to help others in the community.

    1 person found this answer helpful.
    0 comments No comments

  2. Chris Csanyi 41 Reputation points

    Thanks for the idea but i have changed everything about the record and still matching back to the Salesforce ID. Where is Salesforce ID stored on the Azure side? That is where I am stuck and can find much details that I understand to break this connection. I have it set to match to username. So the Azure user ID is staying the same with a newer non full salesforce license and all works fine besides provisioning keeps matching to old salesforce ID. I even manual made new account for the person and it works just fine.

    Examples below



  3. Chris Csanyi 41 Reputation points

    @AmanpreetSingh-MSFT thanks so much this looks promising! I am going to test this shortly on my sandbox to make sure that it works how it should. So going forward I would not have to update the users email it sounds like because the first time it goes it looking at the username and if I change that to the deactivated Salesforce account with username_old going forward it would look at the correct record after the scope reset. I could always see in the detail logs the salesforce ID just could not figure out how or where it was getting setup at.

    0 comments No comments