Azure Active Directory SaaS Provisioning Behavior

This post is an in-depth looks at Azure Active Directory (AAD) SaaS provisioning behavior, giving you the ins and outs before enabling it in your own organization. If you haven’t read part one in this series I suggest you start there to get an understanding of attribute mappings and matching rules. Here are some sample cases and their results:
Case 1: New user in AAD provisioned as a new user in Salesforce.
Once you assign users/groups to Salesforce in AAD you will be presented with a profile option to assign. If you are assigning a group this profile will be used for all members and future members of that group. The Salesforce profile dictates what permissions a user has in Salesforce and will affect your licensing cost so definitely work with your Salesforce team to work this out.AzureADSaaSProvBeh1AzureADSaaSProvBeh2
AzureADSaaSProvBeh4Once a user is added to the group then it will be provisioned to Salesforce.AzureADSaaSProvBeh3I can see the details of this in the Azure provisioning logs.AzureADSaaSProvBeh5Case 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.AzureADSaaSProvBeh6I have an existing user in Salesforce.AzureADSaaSProvBeh7Then I’ll create a new AAD user with the same UPN.AzureADSaaSProvBeh8I’ll then add the AAD user into a group that has been assigned to Salesforce.

AzureADSaaSProvBeh9

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.

AzureADSaaSProvBeh10

You can observe the provisioning log in Azure to see how the account was handled.

 

AzureADSaaSProvBeh11

 

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.

AzureADSaaSProvBehCase3

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 planning 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.

AzureADSaaSProvBehCase5A

Azure AD will run a sync and re-enable this account if the user for is Active is meet with a true value.

The default mapping for is Active:

AzureADSaaSProvBehCase5B

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.