In my current project I’ve created around 40 Workflows and over 80 MPRs – and this is just phase one! In an effort to keep things tidy I’ve been using naming conventions and a consistent design approach, and one thing I found myself doing was separating MPRs that grant permissions from MPRs that run Workflows.
This struck me as a good idea for a number of reasons.
Mostly you want to trigger Workflow based on something changing but you don’t much care how the change happened. The Set transition MPR is ideally suited here – we don’t care how the object got into the set, but it did, so now we’re going to do something else.
However it’s often better to use a Request MPR so that the resulting changes are still tied to the original (“parent”) request and you can, for example, send a notification back to the original Requestor.
In a typical FIM Portal environment you will have a number of MPRs granting access to the same resource type – for example:
- Self can change some attributes,
- Manager can change some attributes,
- Particular people may be designated elevated access – eg., Helpdesk, IT Support, department assistants.
All of this can stack up to a number of permission-granting MPRs which overlap on their attribute inclusion lists.
Now let us say you also want to launch workflows when certain attributes change. The only way to do this is to target the MPR at the specific attribute/s where a change should trigger the particular workflow. If these MPRs also grant permissions you run the risk of one requestor triggering the same workflow multiple times – perhaps because they’re a department assistant but changing their own profile. When two workflows try to change the same attribute in the one request the result is “Cannot insert duplicate key row” errors and a failure of both workflows.
When you separate the MPRs into those that grant permissions and those that run workflows, things become a lot simpler. Now all your request-type workflow MPRs can generically have “All People” as the Requestor Set, because your permission granting MPRs will be restricting who can actually make this change anyway. Ideally you will also have each Workflow being called by only one MPR.
I now have a bunch of “Access Control” MPRs and a bunch of “Workflow” MPRs and I’ll be keeping it that way!
When I mentioned to Bob Bradley that I’d done this his response was “oh yes I always do it that way” – so that, to me, is a Best Practise!
