OIM Howto: Cascading user form changes with approval

The OIM user self service function makes it possible for the user to update attributes on their own user form. This of course makes it possible to trigger provisioning events based on the updates but in many cases you need an approval workflow to ensure that the user does not give itself inappropriate privileges. How do you do that?

Lets say you have a field called "primary role" on the user form that the user can update. On update of this field you want an approval process to be fired and if the change is approved "something" should happen through a provisioning task.

The first question is how do you detect the change to the user form? This can be done through an entity adapter set on post update on the user. This adapter will be fired on any update to the user form so you need to add an additional and invisble field to the user form called "primary role old". The first thing you do in the adapter is to check if "primary role" and "primary role old" are the same. If so no change has been done to this field and do nothing. If not then fire off the request. At the end update "primary role old" to be the same as "primary role". This will trigger a second round of entity adapter check but as the two attributes now are the same nothing will happen.

Next you need to create a custom resourve object with the associated object form, process form, approval process and provisioning process.

Firing off the request for your shiny new resource object is done using the createRequest API from the tcRequestOperationsIntf class. The details for how to do this can be found in this OTN discussion on creating requests

Now the update to the user form will create a request that is approved (or denied) by the appropriate parties and your users get provisioned with whatever you want to put in your provisioning process. Elegant isn't it?

If you have more than one field on the user form that needs this treatment I strongly recommend that you use a single entity adapter instead of one adapter per field as entity adapter are expensive to instantiate and your user updates will get very, very slow if you have 10+ entity adapters with each one looking at a specific attribute.