Once a user is added to the group then it will be provisioned to Salesforce.I can see the details of this in the Azure provisioning logs.Case 2: New user in AAD matched with an existing Salesforce user.This scenario is a great example if you are configuring AAD provisioning and you’re already using Salesforce. You want to ensure that you don’t turn this on and then create a bunch of duplicate accounts, right. Back in part one I gave an overview of matching rules. These are here to match on existing accounts and not create duplicates. Once an account is matched then the attribute flows are brought into effect and update the attributes in Salesforce. It will also change the Salesforce profile if the assigned one does not match the existing in Salesforce.I have the default match rule in place in Azure.I have an existing user in Salesforce.
Then I’ll create a new AAD user with the same UPN.
I’ll then add the AAD user into a group that has been assigned to Salesforce.
It takes roughly 5 – 10 minutes before the provisioning is complete. In Azure there are reports that contain provisioning data but it is slower to update than the actual provisioning action.
Once provisioning is complete you’ll see that the attributes Title, Company, and Department were updated from Azure AD.
You can observe the provisioning log in Azure to see how the account was handled.
Case 3: Azure AD attribute mapping addition.
When you add an additional mapping in the attribute mapping section a full sync will triggered in order to update all the provisioned accounts with the new/updated values. This can be seen in the provisioning log.
Case 4: Manual changes to mapped attributes in Salesforce.
What happens if a Salesforce admin changes any of the attributes that AAD is synchronizing? In true state based synchronization fashion AAD will overwrite the changed values with what Azure AD has.
This is another planing session for you to have with your Salesforce administrators.
Case 5: Deletion of Salesforce account but AAD account still exists
Salesforce doesn’t have a delete user function available in their system. The available option is to make the user inactive.
Azure AD will run a sync and re-enable this account if the user for isActive is meet with a true value.
The default mapping for isActive:
If the account isn’t in the Azure AD recycle bin then it will be set to true. If the account has been deleted in Azure then it will be set to not active in inactive.
There are timing considerations to take in account but if you enable provisioning you should let Azure AD be the source of truth in Salesforce for the attributes it manages.