Identity and Access Management is all about the authoritative system.  The identity source of truth.  Most often it is the HR system, but for some very important information it is your users.

What you can't automate, you delegate.  And this is especially true for user identity information such as mobile phone, home address, or other personal identity information.  Your end users know this information, you and HR probably don't.

The solution is to give them Active Directory self service.  Delegate the ability to update pertinent identity information in AD but only the pertinent information.  You will need role based access control to determine what the end user can and cannot update.  Let them view title but not edit it.  Allow them to update their office phone but put an approval workflow in place for their manager or the help desk to confirm it. 

But this information belongs in more places than Active Directory.  If your user updates her home address, that information should flow to your payroll application.  If mobile phone is updated, that should flow to your emergency contact list.  Identity is a lot more far reaching than Active Directory, but AD is the place that your users understand; it's the global address list, they see it all the time.

Some information goes the other way.  Your user gets a promotion and the new title is put into the HR system, that information needs to flow to Active Directory.  That same promotion prompts the user to need access to the customer portal and that information flows directly to that portal, provisioning an account if necessary.

Having a metadirectory functioning in a hub and spoke model allows you to configure these attribute flows easily and efficiently.  The EmpowerID metadirectory gives a visual attribute flow to determine which identity store is authoritative and which is a recipient.  You can also have a "first wins" scenario, taking the last change regardless of which system is the originator.

The metadirectory "hub" keeps a record of all changes, allowing you to audit which system recorded the change, when where and how.  You can roll back changes, apply additional workflow actions to any change, and audit these changes periodically.

The idea of adding a workflow to an automated change might seem counterintuitive but the idea is to have identity controls in place for applications that don't necessarily have controls.  Active Directory is a great example.  If you have ADUC access, you have ADUC access.  You want to have role based access where users can manage some attributes, managers can manage more, the help desk even more, and the admins to have more access.

Having a check and balance on each of those powers is important.  Think about this, the users with the most privilege (domain admins and senior executives) also have the most ability to bypass your security.  If you ran an audit on users with passwords set to never expire, the list would most likely be littered with names from those two sets.  And, they are the users you need the most secure.

So if a change comes from ADUC into the metadirectory on a particularly important attribute (say, relating to password policy), put a control in place.  Have another domain admin approve it even though it was an automated feed.  Same thing for title, kick off a workflow when someone's title change from HR contains VP or "Chief".  This is simple checks and balances just like we all learned in the 5th grade.

The metadirectory gives you an easily managed model to flow identity information to the correct identity stores.  It allows you to automate AND delegate.  And, it enables auditing to a level that native application access won't.