As this old 2009 post on the Bobby and Nima blog attests to, there is often value in turning on the ROPU setting on a FIM2010 workflow – even if it’s only temporarily.

My use case is a workflow which adds a sync rule to a target user object to write back an email address to an HR system … in this case actually this means creating a contact record with the new email.  During testing I had found that bulk emails initiated from an HR platform to live users when their email was set had the potential to be career limiting – and I needed to introduce an override concept.  This I did by implementing a sync rule parameter and testing for the presence of a value in the supplied parameter in the EAF for email.  If a value was set I would use that instead of the email bound to my user object. Simple enough idea, and did the trick nicely.  That is until the default email value for existing users needed changing …

Changing the parameter on the workflow is the obvious first step – but this of course didn’t affect the existing EREs.  Enter ROPU.  Simply disabling and re-enabling my MPR re-triggered my workflow (set transition IN) for every user in scope of my ResourceFinalSet – sure this was a lot of activity in a short period of time, but it did the trick.

Note that I find it is ALWAYS good practice to remove any existing SR as the first step of my workflow before adding any new SRs … otherwise you can get the same SR added many times over.