In the short time I have been using FIM I start to believe that it is not designed as a tool to solve business needs but rather a vehicle to enrich FIM consultants. What we are trying to do is this: For NEW employees (those that appear in FIM Portal as a user) Run a Workflow which has 4 activities: 1. Generate a password and store it in a Parameter. 2. Run as IN/Outbound Sync Rule SR1 to Provision new AD account using Password made in step 1 in an OU based on EmployeeType/Location 3. Send a Notification Email to new guy's Manager with new user details + password 4. Send a Notification to Interested Parties with new user details BUT NOT THE PASSWORD I can do this. I think the WF is best NOT run on Policy update only Run when the user transitions IN to a set. The Sync Rule is checked so that it can create accounts in target system which is just what I want. If I decouple the notification from the Password generation and AD account create Workflow then nobody knows the password. BUT. I also need to cater for changes in Titles, Employee Types and changes in Location which mean a move/renamed dn in AD etc. Here I do NOT want to send any notification. I have thought of a second triple of Set/MPR/WorkFlow and a subtly different Sync Rule. SR2 For existing Users My Workflow just consists of ONE activity, the IN/Outbound Sync Rule SR2. This is governed by an MPR which is triggered for For request changes to existant FIM users. This can be marked run on Policy update because I am not going to send notifications or set passwords. For safety I am not checking the Create account in target system tick-box in SR2. But if I do this will this stop any rename events? What worries me greatly is the fact that both Workflows could be called by FIM and that my sync Rules could be applied at the same time. Because once the user is transitioned IN he is within scope of existing users so the second MPR wakes up... or does FIM take care of this????? What I do NOT want to happen is both of my Sync Rules to be running at the same time. For safety I dont want to check the create account in target system and definitely not flow an password attribute in the Sync Rule SR2, but in SR2 I do want to be able to change the DN. What I do NOT wish to happen is that the situation where FIM starts both MPRs and so the Workflows and I get a situation where SR2 is trying to provision the new account rather than SR1. How do I prevent this?

I'm not following why you need two sync rules here. The existing ones you use will handle updates as the metaverse changes, the import/export flows will be honored on the sync rules.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

I'm not following why you need two sync rules here. The existing ones you use will handle updates as the metaverse changes, the import/export flows will be honored on the sync rules.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Like Brian mentioned, you don't need multiple sync rules, just one. The terminology may be the confusion. When you transition into a set that applies a sync rule to a person, the addition of the sync rule is a one-time event. Once the sync rule is applied to the person, the flow rules take effect from then on - until a workflow runs that explicitly removes the sync rule from the user. FIM (or most IDM toolsets for that matter) aren't as simple and obvious in their operation as we'd like them to be. The tools are complex and varied because the problems they solve are varied and complex. If everyone did Identity Management the same way, the tools would probably be tuned toward specific scenarios, but since the problems we solve can be so varied, the tools end up being more generic and customizable to meet those needs. Hang in there. The more you use the system, the better you get at it. There are lots of good documents online as well as classroom and online training, and you could even enlist the assistance of some of those FIM consultants you mentioned. Frank C. Drewes III - Architect - Oxford Computer Group

Ok. Now I am understanding. Its the RULE which is obeyed ever-after not the workflow when the user is updated.