Here's my scenario: I have 2 MA's: one connected to my HR database's employee table. The employeeID is the anchor. It is projected into the metaverse. the other connected to AD. Some of the user accounts have the employeeID attribute set. It is JOINed to the metaverse using the employeeID. This means that if the AD user matches the employeeID of a metaverse obj, it's connected to it. If the AD user has no employeeID or if there's no metaverse (HR) obj with the employeeID, a disconnector is created. This works fine except if the employeeID in the AD user CHANGES, say because the admin typed it in wrong. The connection between the AD connector space obj and the metaverse obj does not change as I'd hoped it would when the AD MA import/sync occurs. Sample objects: HR obj #1: employeeID=1, givenName=moe HR obj #2: employeeID=2, givenName=larry AD obj #1: employeeID=2, mail=moe@stooges.org import and sync creates 2 HR objs, 2 metaverse objs, and 1 AD obj connected to the metaverse obj projected by HR obj #2. metaverse obj #1: employeeID=1, givenName=moe, mail=<not set> metaverse obj #2: employeeID=2, givenName=larry, mail=moe@stooges.org If I change the employeeID of AD obj #1 from 2 to 1 and rerun the import/sync, nothing changes in the metaverse despite the fact that the connection between AD#1 and meta#2 no longer obeys the JOIN rule.

Hi There, <soapbox> This is one of those cases that I usually try to show when I'm teaching the FIM training course. In a lot of instances where there is manually maintained information, it is better to use join rules (or relationship criteria) that have at least two attributes being matched. This minimizes the issues of incorrect joins which cause the issues you're dealing with. </soapbox> That said, you can use the "disconnect" function in code to break the connection if you see that the employee ID's no longer match. Refer to the developers reference on the best way to use this in your situation. This would allow you to break the connection between the MV and CS objects therefore allowing you to rejoin the object to something else again during the next synchronization cycle. Now, you need to take into account that if you have the deprovisioning logic set to "delete on the next export run", running the disconnection may actually trigger a deletion of this account inadvertently. You will probably want to look at replacing that function with a rules extension as well so that if you have manually disconnected it, it won't be deleted but on the other hand if it was disconnected for some other reason, you do want it deleted. Thanks B

Thanks. Of course, I hoped this scenario would be handled OOTB. But custom code is better than "it can't be done".