So you’re setting up a FIM lab and you’re shooting from the hip because this is the envisioning phase of your project (i.e. you haven’t written your design yet). You’ve setup an outbound synchronization rule (OSR), a workflow (WF) and a management policy rule (MPR) to run the WF. The public documentation refers to this as a “synchronization triple”. The MPR is a set transition MPR, ST-MPR, the target set is “All Active People”. You already have a bunch of users in the FIM Service that are already members of the all active people set. OK, you run a delta import on the FIM MA followed by a full synchronization (as your SRs have changed because you’ve just imported a new SR). Declarative, a.k.a. codeless, provisioning doesn’t occur. The metaverse (MV) objects are not provisioned into the connector space (CS) of your target system (connected data source, CDS or managed identity system). Why not? Well, two reasons immediately spring to mind:
- Declarative provisioning isn’t enabled. You enable this via the FIM Synchronization Service Manager. Click the management agent (MA) tab, click tools then options (Ctrl + Shift + O) and select “Enable Synchronization Rule Provisioning” (fig. 1, below).
- You don’t have an expected rule entry (ERE) resource. This is the crux of this blog post. Basically, your users are already members of the transition-in set in your ST-MPR definition therefore the WF to add the target users to the OSR didn’t fire.
How to make this fire? In the lab, go back to your WF definition and enable “Run on policy update”. Now disable the ST-MPR and immediately enable it again. Check the request log (All Requests, hit search). You’ll see one “System Event Request” for each resource in the set. In addition you’ll see a “Create ExpectedRuleEntry: ‘<SR name>’ Request” followed by the System Event Request’s child request: “Update to Person: ‘<Target>’ Request”. The system creates an ERE and updates the target of the system event. If you inspect the request you’ll see that the previously created ERE has been written to the Expected Rules List (ERL) attribute of the target user.
Now, when you import and synchronise the FIM MA again you’ll get a projection for each ERE followed by outbound provisioning and synchronisation into the CS of the MA in question.
So what’s the point of this blog post? Well, it’s a reasonably common question on the FIM forum. We’ve utilised retroactive policy application to reapply an Action WF and regenerate (or in the case of the above example, generate) EREs. The same approach can be used to regenerate EREs if you’ve made changes to your OSR and you are making use of Synchronization Workflow Parameters (these values are actually embedded in the ERE itself and are not configured attribute flows that flow through the MV object).
So what happens if I’ve not used a set transition MPR? That is, what if I’ve used a request MPR?
Well, this is easy. You just need to fire the MPR. To do that a valid requestor (a user in the defined set of requestors) must perform whatever action is defined by the MPR, e.g. create a user and ensure that the display name attribute is part of the create request. For Synchronization Rule activity WF instances however, set transition MPRs are best. As you have the ability to utilise retroactive policy application (run on policy update) to reapply the WF if you ever need to and you abstract yourself from the underlying request that causes the transition, e.g. you can fire on not just a create but also certain modification operations, without an all-encompassing request MPR that could misfire.
I mentioned a bunch of FIM concepts in this post. If you want to do some more reading on any of these things check out the following documentation:
Understanding Data Synchronization with External Systems (which provides links to the following too).