Understanding Run on Policy Update

Understanding Run on Policy Update

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:

  1. You are creating a new Management Policy Rule (MPR), such as one to provision all users an AD account, and you want one or more of the action workflows in your new MPR to be applied, upon creation of the MPR, to all the members of the MPR's Resource Final Set (also referred to as "Target Resource Definition After Request" in the portal's MPR wizard).
    For example, you may be creating a new MPR to apply a new Synchronization Rule to all users.
    You may want to retroactively enforce this new policy by applying the Synchronization Rule workflow to all users that already exist.
  2. You are enabling a previously disabled MPR, and you want one or more of the action workflows in the MPR to be applied, upon enabling of the MPR, to all the members of the MPR's Resource Final Set.
  3. You are adding a new action workflow to an existing MPR, and you want the new workflow to be applied to all the members of the MPR's Resource Final Set, immediately upon adding the workflow to the MPR.
  4. You are modifying the Resource Final Set of an existing MPR to reference a new set, and you want one or more of the MPR's action workflows to be applied to all the members of the new Resource Final Set, immediately upon modification of the MPR.
  5. You are manually modifying the membership of the Resource Final Set of an MPR, either by modifying the set's Filter or ExplictMember attribute, and you want one or more of the MPR's action workflows to be applied to all the *new* members of the new Resource Final Set, immediately upon modification of the set.

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.

User Request Resulting Action by the FIM Service
Create new MPR Apply each "Run on Policy Update" enabled action workflow referenced by the new MPR to all members of the MPR's ResourceFinalSet.
Enable an existing MPR Apply each "Run on Policy Update" enabled action workflow referenced by the enabled MPR to all members of the MPR's ResourceFinalSet.
Select a new ResourceFinalSet for an existing MPR Apply each "Run on Policy Update" enabled action workflow referenced by the MPR, to all members of the new set referenced by the ResourceFinalSet attribute.
Add a new "Run on Policy Update" enabled action workflow to an existing MPR Apply the newly added action workflow to all members of the MPR’s ResourceFinalSet.
Modify the filter of a set For all MPRs whose ResourceFinalSet references the set being modified, apply each "Run on Policy Update" enabled action workflow mapped to the MPR to each resource that transitions into the set because of the filter update.
Update explicit membership of a set For all MPRs whose ResourceFinalSet references the set being modified, apply each "Run on Policy Update" enabled action workflow mapped to the MPR to each resource that that is added to the set.

 

  note Note
  Simply enabling the “Run on Policy Update” option for a workflow does not result in the workflow being automatically run.
The workflow will only be run upon completion of one of the requests outlined in the table above.

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).

Leave a Comment
  • Please add 7 and 1 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • 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.

Page 1 of 1 (6 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Ed Price MSFT edited Original. Comment: Updated title to standards.

  • Ed Price MSFT edited Revision 1. Comment: Typo in the title

  • Markus Vilcinskas edited Revision 3. Comment: This is a conceptual introduction and not a how to walkthrough

  • Ed Price MSFT edited Revision 4. Comment: Updated title per style standards.

  • Ed Price MSFT edited Revision 5. Comment: Updated font to Segoe UI, size 12.

  • Ed Price - MSFT edited Revision 7. Comment: White space issues and minor title edit.

  • 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 ...

Page 1 of 1 (7 items)