A while back I had a customer who wanted to prevent certain users to re-open a won opportunity in Dynamics 365. They asked if there was a security setting in security roles that could do that, but as we all know this type of granular security is not available in security roles. We can give people different types access of to records, like update, write and viewing, but this is not based on another field like in this case the status field. There are of course other options to accomplish this type of behavior, such as getting a developer involved to write code or plugin but I always try to stay away from coding if at all possible.
So I ended up looking at real time workflows, and I came up with a solution to this problem.
I added a checkbox to the user record called ‘Can reopen won opportunities’ so that my workflow could check whether or not the user should be able to perform this action. If the ‘Can reopen won opportunities’ field was set to ‘No’ then I would have the workflow cancel the status change and show an error message.
My problem at this point was the ability to get to the user who was trying to reopen the opportunity. As we all know, we can’t have the workflow check the user that is running it, so I needed to think about how to do this. Here is the solution I came up with: The workflow would need to run before the status change took place. I had the workflow update a hidden field (I used the ‘Quote Comments’ field, but you can use any field or create a custom field) so that the ‘Modify By’ field was now set to the user trying to make the change.
The second step in my work flow was to now check the user in the ‘Modified By’ field to see if they had permission to reopen the won opportunity; if this was the case then the opportunity status gets changed to ‘Open’, if this was not the case, then an error message is shown. See below for the workflow logic.
Fields & Forms
– Add custom two option field ‘Can reopen opportunities’ to user entity
– Add field to the user form
-Create a real time workflow on the opportunity entity
-Start before record status changes – If we set this to after record status changes the opportunity status change will already have happened, and it will be too late.
– Execute as: ‘The user who made changes to the record’ – this is very important, if we don’t set this right we won’t be able to get the correct user in the ‘Modify By’ field of the opportunity
As you can see in the flow chart above, there are a few conditions we need to configure in the workflow. We want to make sure the current opportunity status of the record that’s being changed is ‘Won’. If this is the case, then we want to populate a field on the opportunity so that the ‘Modified By’ field is now populated with the user trying to reopen the opportunity, and we can check the user record.
If the user doesn’t have the ‘Can reopen won opportunities’ set to ‘Yes’, I’ll cancel the workflow, and I will be able to configure an error message pop up that will be shown to users.
Lastly below is an image of the entire workflow. I hope you enjoyed the post, be sure to check in again next week for my next post!