I did not realize that when you have a new Person being synced from the MV to the Portal, the Manager attribute is not part of the initial create Person request. After the Person has been created then in a separate request the Manager attribute is populated. I wonder why? When I do a create Person via PowerShell and I add the Manager as part of the request, it gets created and manager set all in one create Person request. Could it be that the code within the Sync engine needs the Person to exist before it resolves the Manager value? Anyone know that answer pray, do tell, as Sherlock Holmes would say…ha-ha.
Anyway, my new account notifications to the manager are messed up because I discovered sometimes the gap between the create person and the manager request was up to 15 seconds, and the notification workflow has already fired off. The result is the error message saying manager not found.
Well I had several new account notifications all bunched up into one workflow. I had to
1/ Separate the Manager notification activity. Create a workflow called “Manager new account notification” that contains this activity. It should only be executed if Manager email is present.
2/ Create a Set called “Manager new account notification”, same as the Target set I have for the new account notifications except I added a new criteria – Manager must be in All People set
3/ Create a transition-in MPR called “Manager new account notification”, target set is (2) and attach workflow from (1)
2 thoughts on “MIM 2016: Syncing the Manager from the metaverse to the Portal”
The manager is a reference attribute so it must exist in the MV if you want it to be populated when you export the new account to the portal for the first time. Always works for me!
It does exist in the MV for me, Rob. But when it is sent as part of a new user request it is done in 2 steps. Test that out and see.