There was a question recently on CRMUG about how to modify security to prevent users from Deactivating Contacts.
In Dynamics 365, the security roles can be configured (and is best practice) to prevent users from deleting records.
Removing Delete Option Generally a good idea.Deactivating records is generally a safer process as it can be reversed and no information is lost. However, there may be processes and reports that will only pull data from active records so it may be a business requirement to prevent users from deactivating records.
Since “deactivating” a contact is really just modifying a field value (status “active” to “inactive”) the privilege is controlled by the “edit” permission. Obviously users need to add and edit records!
One solution is to use the Ribbon Workbench and edit the menu to hide/show the deactivate button based on security roles. This is a viable solution but requires some level of JavaScript and knowledge of the Ribbon workbench, not hard but not exactly a picnic either.
Workflow Solution
Another solution would be to utilize workflow to prevent a user from deactivating a record.
The first thing would be to add a boolean field to the system user record to effectively set the security privelege of being able to deactivate a record (or not). In my example, I will add a restriction on deactivating contacts.
For the User record, I will add a new “permission” boolean field. I also enabled field security to prevent modification but unauthorized users.
Once the field is added to entity, it will need to be placed on the form.
The next step will be to create a synchronous workflow that is triggered anytime the record status changes. The workflow will check to see if the record’s status is “inactive” and if the “Last Modified User” actually has the permission to deactivate the record.
The workflow needs to be synchronous because we want the user to know immediately that they are not allowed to deactivate the contact.
The first condition to check would be to see if the status has been set to “inactive” and also to check if the last modified by user has the permission to deactivate records.
If the conditions are met, the next step is to set the contact “back” to being active.
Once the contact is set back to active, it is courtesy to let the user know (so they don’t think that they are going crazy).
How come the Deactivate didn’t work?Use the “Cancel Workflow” step.
The reason why we want the “cancel workflow” is so that an error message will be surfaced to the end user.
In the “Set Properties” you can put in your own custom error message.
Save and activate the workflow.
You will then need to set the appropriate “permission” on the user record.
You will also need to setup a Field Security profile so that users will be able to “read” the value from the user records. You can add the default Business Unit team to this profile to easily provide this access.
Now, a user will still be able to attempt to “deactivate” a record…
However, once the user continues, a Business Process message will appear (showing the custom error message)
While this might not be the most elegant solution, it will serve the purpose.
What it also highlights is yet another example of the possibilities of the configuration options using Dynamics 365.