Somewhat hidden within Forefront Identity Manager 2010, there is a very useful feature for action workflows called "Run on Policy Update". Here are the situations where you may find this feature useful:
The "Run on Policy Update" feature is an option that lives on action workflow definitions, as an attribute labeled "RunOnPolicyUpdate" bound to the WorkflowDefinition resource type. When this boolean attribute is set to "true" for a given action workflow, if any of the 5 scenarios above are encountered with an MPR that uses this workflow, the workflow will be automatically applied to the members of the Resource Final Set of the MPR. Following is a table that summarizes the cases where a "Run on Policy Update" enabled action workflow is applied, in addition to the normal cases where a new Request satisfies all the criteria of an MPR that uses the workflow.
Disabling the “Run on Policy Update” option for a workflow will allow you to perform any of the user requests outlined above, without the workflow being automatically run. If you submit one of the user requests outlined above, thereby triggering the execution of a “Run on Policy Update” enabled action workflow, you can cancel all the workflows that have been triggered by simply cancelling the request that triggered them (eg. cancel the request tracking the creation of the MPR).
Ed Price - MSFT edited Revision 7. Comment: White space issues and minor title edit.
Ed Price MSFT edited Revision 5. Comment: Updated font to Segoe UI, size 12.
Ed Price MSFT edited Revision 4. Comment: Updated title per style standards.
Markus Vilcinskas edited Revision 3. Comment: This is a conceptual introduction and not a how to walkthrough
Ed Price MSFT edited Revision 1. Comment: Typo in the title
Ed Price MSFT edited Original. Comment: Updated title to standards.
Markus - I use all 5 of these variations all of the time, especially in the BUILD phase where I am
(1) continually refining policy and re-applying it;
(2) fixing up bad data;
(3) generating test data;
(4) mimicking the progress of time for a temporal set;
(5) reinstating the FIM database to a previous state;
... and various other scenarios.
One example is that I invariably re-use a couple of generic workflow activities in a workflow configured this way so that I can reset a heap of common attributes for a resource type. I generally leave the MPR disabled by default, and when I want to reuse the workflow I simply adjust the activities to clear/set the attributes I want, and re-enable the MPR to trigger a bulk update, before disabling the MPR again.
I recently extended this idea to create a set of "housekeeping" tasks ... whereby I schedule the regular enabling/disabling of such an MPR at regular intervals to perform integrity checks via an entirely Portal-driven process (as opposed to using externally scheduled/triggered alternatives). You have just reminded me about this, and I think that sounds like a new wiki article for me to write up ...