Users' Manager field is always null. Why isn't it set in the CDS if it is set in Azure AD?

[CBatt]

All of our User (systemuser) records are present in all of our CDS instances, except that in every case the Manager (parentsystemuserid) field is always null. Our assumption/expectation is that the Manager field should be set to reference the proper User record in the CDS if the Manager is set on the User object in Azure AD.

Is our assumption correct? If so, is this something where we should contact MS Support, or is there something we can do ourselves to resolve the problem?

(Not sure where this question belongs, so I'm posting it in multiple places.)

[rocamp]

Hi @CBatt ,

The manager field does not come over from Azure AD into the CDS Manager field. I tried out a couple of different Flow variations to take that value and populate it, but I have yet to be successful. I will keep trying and let you know what I find.

[GarryPope]

Hello @CBatt,

We've been using Dynamics for almost four years and the "Manager" field is always blank for us. We had to manually populate it. But as @rocamp said, you could probably populate this with Power Automate. 

So when a user record is created, a Flow can run and get the user's manager's details from, I think, the Office 365 Users connector, and then get it to populate the user record field of Manager.

The only thing you'll need to factor in is if the Manager doesn't have a record in the CDS. An example of this might be if you have a security group tied to your environment and the manager is not added to that security group, then they wouldn't show in the environment.

Good luck,

Garry 

[CBatt]

Thanks @rocamp and @GarryPope. It's unfortunate, but not entirely unexpected.

I did manage to create a Power Automate Flow. I don't really know how to share it, but the gist is:

• Use the CDS (Current Environment) List records action, to get all of the User entity records
• Loop through the records
  • Use the O365 Users Get Manager (V2) action, passing in the User Principal Name (i.e. domainname) of the current User record
  • Use the CDS (Current Environment) List records action, again, but this time filtered by "domainname eq '@{outputs('Get_manager_(V2)_of_User')?['body/userPrincipalName']}'", to get the User record corresponding to the manager found in the previous step
  • Loop through the manager records (because List records returns a set; I didn't have time to figure out if/how to directly access the first record of the result set, so yeah... hackety hack)
    • Use the Common Data Service(*!) Update action to update the manager field on the User entity

I wrapped up the sections with some scope blocks to simulate "try...catch" exception handling, added a couple of debugging convenience actions, set outer loop to work in parallel, and voila... it runs in about a minute on our 690 users or so.

The key was that the newer Common Data Service (Current Environment) connector would not allow me to update the Manager field of the User entity, nor would it allow me to execute the "SetParentSystemUser" bound action, but the older Common Data Service connector works.

For what it's worth, I also tried to build a Dataflow, but failed. No surprise, as it is still in preview as of time of writing. Biggest problem: can't update the manager field of the User entity. It's simply not a field you can map to. I only discovered this after spending a lot of time wrestling with getting Power Query to work with the MS Graph API, which it reads super slowly (roughly 7-9 minutes just to read the necessary data; whereas my flow above takes about 1 minute to read and update) and doesn't offer the same functionality that can be experienced with the MS Graph Explorer online tool (e.g. get /users works, but /users?$expand=manager fails, so you have to do a couple of self joins on the data). Hopefully Dataflow will be improved by future updates.