Get & set manager of CDS|D365 users with Power Automate flow

Two years ago I wrote a blog post (‘User attribute values lost in synchronization > Flow to the rescue: Manager‘) about how to use Power Automate flow to automatically set the manager field for a Dynamics 365 User record based on the Manager attribute in Azure AD and Office 365. My site statistics show that it’s visited regularly, and I received the question in the comments whether this solution is still valid. Well, the answer to this is yes and no. The Manager attribute is not synced to the created user record by the system itself, but the Dynamics 365 connector that I used in the blog post is deprecated. So I’ve decided to write a new blog post with an updated version of the solution, based on the Common Data Service (current environment) connector and new insights on how to set up the flow.

The flow supports the following scenarios:

1. When the Manager attribute on the Azure AD|Office 365 user profile has a value and the User record of this manager is available (disabled or enabled) in the Common Data Service environment, the manager is set on the User record
2. When the Manager attribute on the Azure AD|Office 365 user profile has a value but the User record of this manager doesn’t exist in the Common Data Service environment (when the user is not licensed for CDS|D365 and/or not member of the security group that gives access to the environment), the user profile of the manager can be synced to the Common Data Service and the resulting record id is set on the User record
3. When the Manager attribute on the Azure AD|Office 365 user profile is empty, the flow action will fail and the flow will jump to the next record in the Apply to each loop. The overall status of the flow run will be ‘Failed’ and the flow will be disabled by Microsoft Flow when it has failed consistently for 14 days. But in this case we will set the status to ‘Cancelled’ to prevent this from happening.

This is the overview of the flow:

The flow is started by a Recurrence trigger to run the sync process daily for example. The first action is to initialize a variable of the type Boolean with a value of true or false, and this is checked in a Condition control to let the Force Sync user action run or not. The choice is up to you.

Then a List records action will get us all User records with Access Mode ‘Read-Write’ to filter out the application and system users. The attributes in the output are limited by the Select Query, and two attributes of the related Manager record (User entity) are added by the Expand Query.

The next step is to initialize a variable of the type Array and set the value of the output of the ‘List record Users’ action. This array is used to append the newly created user in case of the Force Sync user action, so this User record will be available to get & set the manager for the following Active User records in the Apply to each loop.

In the ‘Filter array Active Users’ action the output of the ‘List records Users’ action is filtered (isdisabled eq false), so we only get the active users to get & set the manager for.

Within the Apply to each Active User control, the ‘Get manager (V2)‘ action of the Office 365 Users connector will get the userPrincipalName and id attribute of the manager if it’s present. This action will fail ‘by design‘ if “No manager found for the specified user”. The following actions are then skipped and the flow will jump to the next record in the Apply to each loop.
The ‘Filter array Manager as User’ action filters the UsersArray where the User Name (domainname) is equal to the User Principle Name of the manager, to select the User record of the manager if available.

In the ‘Compose Visual check’ action I’ve added some parts of the rules from the two conditions, so we’re able to check the values in the flow run history because the conditions themselves only give the overall Expression result true or false.
The first Condition checks if the Manager record id on the Active User record is not equal to the record id of the user in the Filter array Manager as User, and if the latter is not empty.

If yes, then the Active User record is updated with the record id of the user in the Filter array Manager as User.

The second Condition checks if the User Name (domainname) of the Manager on the Active User record is not equal to the User Principal Name of the Get Manager (V2) output, and if the ForceSyncUser variable is true.

If yes, then the manager is added as user to the Common Data Service environment with the help of the ‘Force Sync user‘ action from the Power Platform for Admins connector. Be aware that the user will be assigned to the base Business Unit.
The environment is set with the expression workflow()[‘tags’][‘environmentName’] as custom value, and the ObjectId is the id from the output of the ‘Get manager (V2)’ action. This action doesn’t give us any data from the created user as output, so we get the user record with the ‘List records New User’ action.

Then the active user record is updated with the record id of the manager.

To be able to get & set this manager for the next records in the Apply to each loop the User id and User Name (domainname) are added to the UsersArray with the ‘Append to array variable UsersArray’ action.

The final action is to set the status of the flow to ‘Cancelled’ in case of failed ‘Get manager (V2)’ action(s).
Therefore the ‘Configure run after’ in the settings of the Terminate action is set as follows:

Now if the ‘Get manager (V2)’ actions do not fail, the status of the flow run will be ‘Succeeded’, and if they fail the status will be set to ‘Cancelled’ (‘Canceled’ in the UI) to prevent the flow from being disabled by Microsoft.

I’ve added the flow to an unmanaged solution that you can download here.