MPRs should either have “Grants Permission” ticked, or they should trigger Workflows, but preferably not both.
Separating your MPRs in this way makes the Workflow MPRs very simple: they will mostly be either Set Transition types, or will trigger on requests submitted by “All People”.
The permission to actually make a change is meanwhile controlled by the “Grants Permission” MPRs, and here is where you can put all your complexity about who can do what, and under what circumstances.
You also minimise the risk of SQL duplicate key exceptions; the error that happens when two workflows try to update the same attribute as part of the same request. By separating the MPRs you can model how the change can happen with your Grants Permission MPRs, and then have a single Workflow MPR that responds when the request is made.
Hey Carol totally agree with this when you want your workflows to extend to anyone that changes the attribute but I have one example I am currently working on that I believe justifies using the same MPR for the grant and workflow and would like your advice as I haven’t done enough of these to trust myself yet.
I am creating a way for a manager to extend the account expiration of their direct reports. I only want the workflow (that ensures the manager is extending the account no more than 6 months) to trigger when the manager changes the accountExpiration attribute.
So, what is best in your opinion:
Two MPRs, one to grant set attribute to the manager and another MPR to initiate the authorization workflow when the manager changes the attribute
One MPR that grants set attribute to the manager and initiates the authorization workflow
I would still recommend creating the two MPRs. You may also want to give the Manager other permissions to change things – with two MPRs it’s easy to go and modify the Grants Permission one, without any possible impact to the particular change that triggers the WF.
Great point Carol, didn’t think of that. Thanks!