Permission Setting – Preventing Malice vs Accidents

Overview

Permission setting in Dynamics 365 Business Central is a serious, but not serious topic.

When a company coming from a legacy system or no system, they will always want to restrict everything. The older systems are easier to restrict because there’s not a lot of functions you need to worry about. A considerable amount of business processes had to be complimented with manual processes.

In another words, they couldn’t do anything in the legacy system anyway. This is one of the reasons why they’re migrating to Dynamics 365 Business Central.

In my experience, after the company goes live, permission will more likely become an non-issue rather than first priority. The reason is the users can now do a lot more than what their old system can do. They require less time depending on other people for troubleshooting because they have access to troubleshoot the problem on their own.

When operation is smooth, things are smooth.

Nonetheless, when the discussion comes up about setting permissions, there are a few areas and key points to consider.

Ways to Restrict

There are basically 2 fundamental ways you can set security in Dynamics 365 Business Central.

1. Assigning Permission Sets where you control what tables to access as defined by assigning users Permission Sets
2. Profile and Role Configurations where you restrict the user’s access to icons and functions

The combination of setting the permission sets and configuring the personalizations for user roles should net you the exact permissions for your organization.

In addition, there are tools like Recording Permission Sets that allows you to set the permission based on what the user actually does in the system so you don’t need to rely on the standard permission sets for the user.

To restrict what the users can see on a particular page, after you’ve customized their profile roles, you can remove the personalization options so they can’t mess around with showing fields they’re not supposed to see.

Having it Just Right

Administrators will make the mistake of setting too much permission where the user can’t do anything. Every little problem they encounter, they will need to reach out to other departments or the supervisors. Give too little they will access the areas they’re not supposed to access.

The guideline to which I always recommend to clients on setting security and access is: “why are you setting this permission”?

1. Are they using the access to the information for malice?
2. Are you restricting the access because they might make a mistake?

If giving them access to prevent them from making mistake, I will always advocate training instead of restricting.

In the modern workplace, I will always advocate empowering the  users with more, not less, access to information so they can troubleshoot their own problems and make better decisions on their own without having to bug someone else. Everyone is busy enough already.

If they’ll use the information for malice, then we for sure want to restrict them access and remove the functionality from the menu and permission sets. Having said that, I suspect when companies really get down what data users access for malicious reasons, there’s really not much areas that needs restricting.

Conclusion

Permission setting will take a lot of time. People will underestimate the amount of time required to get it just right.

I always recommend that the end user setup security for their own organization. The partner can do the initial framework, but to get everything exactly the way you want it, you have to get your hands dirty. Otherwise, prepare for large consulting bill and still not have it exactly the way you want.

One other caveat is that the more specific you get down to making your permissions “just right”, the more maintenance and overhaul you’ll need to do when your business requirement changes or new functionalities are introduced.

I can’t tell you how much time we have to “undo” restrictive permission sets in order to help move the company forward and expand their utilization of the system they purchased.

I guess the summary of this whole article about setting security is: Give the benefit of the doubt that the users will use the information for good, not evil.

Good luck!