There are HR Feeds to the Sync engine. FIM Provisions new users to AD using code (C#). There is the FIM Portal where new users are also created and managed.
To make all user management to be done in the FIM Portal and NOT direct in AD or via any other tool in AD. To do this it means that the FIM MA will be priority for several fields and I expect FIM to overwrite any value coming for AD that is different from what is in the metaverse.
FIM MA does not block fields that it has nothing to contribute, so say FIm has no telephone number for the user and some one enters it in AD, there is no objection from FIM. Well I won’t flog that topic, enough has been written about it and FIM IDM community hopes for a “real” null contribution option from the FIM MA.
FIM MA does not accept values from other systems lower than it in the attribute precedence list even when FIM MA has nothing to contribute. That was interesting given I have seen AD MA accept values from others lower than it in the list. This rules caused some issues because of the HR Feed. New users from the HR Feed are provisioned via code, and their attributes don’t flow back to the Portal. If attributes of existing users are changed via the HR feed, it also does not go back to the FIM Portal. One could say dump the coded and use only codeless for your provision. Its a bit too far down the road for that without some major redesign. So what is the workaround?
Examine the attributes, determine the one HR should be authoritative for, e,g Job title, department, manager and make it equal precedence or make HR higher than FIM MA.
It still leaves a couple of key fields that will not come over. So in the Portal after the user is provisioned in the sync engine, at least the accountname comes over because I don’t want people changing the SAMaccountname in the portal, that field change has to be reviewed by AD/IDM team. Using the accountname fire off a PowerShell workflow when the new user is synced to Portal, that will query the FIM Metaverse database, pull all the missing attributes and update the Portal.
A note on Attribute flow Precedence
Equal Precedence has its own rules that may cause the “skipped no precendence” or “deleted” message to be seen when provisioning. If you set an attribute as equal precedence and no MA is contributing to that field when you provision to another MA, the sync engine deletes the value. So I have csentry[“mail”].value = firstname.lastname@example.org when I provision to AD but I see no mail in AD. It is almost as if the MV becomes a contributor when its equal precedence and then contributes that famous null that we would all like to have. If the attribute is manual precedence, it all works good.