Is there any way to add a uniqueness constraint to a portal attribute? I want to ensure that any attempt to create or modify an object from the Sync Engine results in a unique EmployeeID. I see that ObjectSID, AccountName and many others have their Usage Keyword set to "Microsoft.ResourceManagement.WebServices". Does this enforce the contraint?Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

seen this: http://technet.microsoft.com/en-us/library/ff519007(WS.10).aspx ? can you link your EmployeeID to ObjectId converted to string? Anyway, I would better submit a record to HR system, get EmployeeID of this new record and then flow EmployeeID back to FIM.

No, that's not what I'm after. I'm not trying to create an employeeID, HR already has one, I am just trying to keep the Sync Engine from creating a duplicate if the value already exists in the portal. There are use cases where it's valid for Operations here to create a user in the portal with the valid employeeID because our HR import is always 24 hours behind.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

oh, understood. Had the same scenario with MIIS + HR + manually created users in AD. I simply put Join rule for HR MA on EmployeeID. So if a user was created in AD (on a portal in your case) with proper EmployeeID it will not have a duplicate during next HR MA stage and sync as this new record from HR will be joined to MV object on EmployeeID. Projection does't happen and there're no duplicates during provisioning. the worst thing is that Operations will have to enter exact empID value as in HR system.

Yeah, that old school solution doesn't work in FIM I'm afraid. What happens is this: Pending Import from HR - employeeID = 123 Admin creates new user in portal - employeeID = 123 HR Inbound Sync Rule in place to create an object in the portal, relationship criteria set to employeID = employeeID If you sync the HR object first it will project to the MV and provision a new Pending Export csobject in the FIMMA. Upon export, a duplicate object is created in the portal. Confirming Import yields both objects: Admin created object does not join but instead projects a new MV object - you cannot configure your own Join rule on the FIMMA HR Provisioned object is synchronized and the pending export is resolved You now have two people in the metaverse and in the FIM portal for the same employeeID If you Import the Admin created object from the FIM potal first, then the object projects a new metaverse object which can be later joined by HR. We have adjusted our run profile execution order to compensate for this but we have now violated a rule of classic sync in that it shouldn't matter which order we run our data sources, we should end up with the same behavior. In my opinion, this is a bug in the Sync Rule process that the relationship criteria should account for and join to the existing MV object.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com

I see... Saw this behavior in a lab and decided to left all provisioning code in MV extension for this reason. And I have to run MAs in the right order to avoid duplicates. I have to use my .dll to check for unique samaacountnames, UPNs, mail addresses, display names and so on - since it was already in MIIS and there's no reason to rewrite it using FIM WFs. I don't think its a bug in the Sync rule engine not to handle join on FIM MA for new objects. I suppose that MS thinks that FIM MA must be the only authoritative source for objects provisioning. if you really want to avoid duplicates and have random MAs run order write a MV extension that will check metaverse for employee ID uniqueness and disconnect all CS objects if mventry("EmployeeID").LastContributingMA is FIM for all objects with non unique empID. But I'm not sure that such approach is good from a design perspective. what about setting sync rule precedence on a FIM portal and turning on dependency on HR sync rule, so HR sync will always be run after FIM MA will provision new objects?

Brad, Did you ever solve this question? I am having the same problem now, only I won't be flowing this ID from an external system. My FIM only custom attribute will be plugged into FIM after the user account has already been provisioned into FIM from AD. Therefore, I need FIM to check for uniqueness on this custom attribute when the admin tries to input it.

I adjusted the run profile order of execution for this customer but Eugene's suggestion of looking into sync rule precedence is interesting and would be worth a try.Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

There is no sync rule to adjust for me. The attribute i want to test uniqueness for is only present in FIM and the Metaverse....it doesn't get flowed into FIM. It is edited with FIM portal and that's it.