Hi, what's the correct approach to delete object from FIM portal having sync rules being removed _before_ object is deleted? Well... having a checkbox 'inactivate' and Transition out MPR to remove a sync rule does the job, but what happens then object is just deleted - FIM raises a PostProcessingError saying 'Target object cannot be found. This can happen if the target object was deleted during the processing of this request' - which is true. The questions is: do I really need to WF activity to remove all sync rules from an object in 'delete MPR' or there's something more simple?

If I read your question correctly, all you need to do is to clear the object's ERL attribute (the references to to the SRs that are gone) and to delete the (in this case) orphaned ERE objects. You can find more details about the relationship between objects and synchronization rules in Understanding data synchronization with external systems. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Markus, the questions is how to avoid orphaned EREs. When object is deleted with red X having a WF that removes sync rules in MPR that grants 'remove object' permissions or in Transition out MPR does nothing but attempts to delete an ERE that has this deleted object as a parent. It looks like ERL has to be cleared in AuthZ stage, right? but it can't be done inside that 'delete object request'.... 'cause clearing ERL attribute during AuthZ stage will raise another request that will also fail... ps. it gives no issues for me except orphaned EREs and not so nice log.

I have approached this in two ways: 1. An AuthZ activity that deletes anything in the target (e.g. [//target/objectid]) resource's DRL and ERL attributes. 2. An Action activity that cleans up any orphaned DREs and EREs (no parent) The reason for #2 is I delete a bunch of stuff via WF, e.g. as the FIM Service which bypasses AuthZ. No issues with #1 other than that a deletion request is noticably slower, to me at least, with the AuthZ that reads and deletes the DRE and ERE.