I'm trying to use a FIM Sync Rules for normal Provisioning from an HR data source, and classic code to provision users created in the FIM portal only. Because FIM does not have a built-in way of generating a unique Account Name, I have to use a sql look-up table in classic code. I know about Tools4FIM's Function Evaluator, and I'm aware of how to do it using custom Windows Workflow, WF. I'd like to understand how this works with normal Sync Rules running side-by-side with class code to provision users based on employeeType, where one type originates from an HR system, and another type is entered from the FIM portal, which in turn generates a unique account name. Anybody? Bueller? Bueller?

Hi Jim, Why not trigger the sync rule by a user transitioning INTO a 'users created by the HR database' set. If none of your current attributes would pertain only to the HR created users, you could just flow a constant value in. I often change the schema and use employeeType for this purpose (I change the validation usually to allow Staff and Student). Usually I'll have two databases, one for staff, one for students. On the staff MA I flow in a constant employeeType of "staff", on the student one I flow in a constant "student", and then I sync employeeType -> employeeType from the metaverse into FIM. I sometimes have two different sync rules for staff and students (when it's easier than having lots of IIFs) and trigger each by a user transitioning into the relevant set. Hope that helps, Paul.

Hmm, I've done it with codeless provisioning rules that only do synchronization while the coded way does the actual provisioning (by unchecking "create resource in external directory" on the sync rule). I think you can probably have both "provision" side by side since I *think* the provisioning extensions get called after the EREs are applied. However, i'd highly recommend you test this lots to see if you can gaurantee the orderingex-MSFT developer, now FIM/MIIS/ILM/WPF/Silverlight consultant | http://blog.aesthetixsoftware.com/

Yeah, my problem here has always been that the Synch Rules in FIM Portal only let you specify object type as the source - you can't apply a specific set because we're dealing with Metaverse objects and not Portal objects (sets only describe portal objects). The only way I could think of doing it is to project your HR users as a different object type (eg 'hrPerson') into the MV. Then for HR users apply one set of synch rules (including "create in external source") and for portal-created users another (excluding "create in external source"). Then with the Provision() method you do your unique account name generation and provisioning for the FIM-Portal ('person') objects. Of course, it becomes complicated if you want to bring your HR users into the portal for any reason, so Ikrima's approach may be best... let FIM Portal do the attribute flow and let coded provisioning rules take care of the actual AD provisioning. - Ross Currie

I ended up moving all the custom code to a custom WF -- yet another technology I had to learn in one night to get FIM to work. (So many moving parts, here.) I was thinking, though. I could create a separate synch rule based on the employeeType attribute. The Portal-Only-flow sync rule would then have the provisioning disabled via "Create resource in external system" option under the Relationship tab. Maybe this will allow the MVExtension code to perform the actual provisioning code. I haven't tried this, because I've moved on to another approach for a solution to generating a unique account name for users created in the Portal only. (Just a rant, found out that dependent sync rules cannot have attributes with "initial flow only". That's bogus. One can't easily chain and reuse sync rule logic together like that.)