Let me know if this sounds familiar. You have been working for months on a Dynamics 365 implementation and you are getting ready for SIT or UAT testing. You realize that everyone has been using the System administrator security role to test all of the functionality up until this point. You need to quickly figure out what roles are needed and implement those roles before your SIT testing begins.
This is probably a worse case scenario for a Dynamics 365 implementation. Implementing security takes quite a while to complete when done correctly. In this blog article I am going to give 4 best practices to ensure your security implementation goes smoothly in your Dynamics 365 project.
Start Early
Probably one of the obvious best practices is to start early. Often though we do not know when to begin. I like to start my security planning during the design phase of the project when the project is just kicking off and requirements are being discovered.
What I like to do is ask my client for a list of their current roles and a description of each. I then take their list of current roles with their descriptions of those roles and identify what out of the box Dynamics 365 F&O role most closely matches the functionality of their current role. Make no mistake this is not perfect and only a roughing in of the security roles that will be necessary. I use this as a starting point as I work through my build phase to start testing and implementing the various security roles that will be necessary.
Speaking of the build phase during build I make sure that the implementation team is testing the various functionality being implemented against the various roles that were identified in the discovery phase. It is at this point that all of the roles are being refined. We may identify roles that need to be changed or perhaps we need completely new roles. The objective here is to, by the end of the build phase, to have a pretty good set of roles that we can go into our validate/testing phase.
Identify the client Security Administrator and Testers
Another task that I find easier to handle in the discover phase of the project is to identify who will be the security administrator for the client. Often I see projects where this role has not been identified until well into the project. If you think about it this is a mandatory role for the client. They need to identify very early in the project who this is. I would encourage you that once this administrator has been identified to have them help you implement the security. Very early in the project you should be teaching them the tools and techniques required to be a security admin in Dynamics 365.
When the testing/validate phase of your project roles around the client security admin should be capable of handling all of the security requests and changes that come out during SIT. I like to use SIT/UAT as a dress rehearsal for the live environment making it as lifelike as possible. This is one area that you definitely want to access as SIT is happening to avoid surprises around security at go live.
Make copies of the out of the box roles
Something that I sometimes see when reviewing projects is when out of the box security roles are being used for security in Dynamics 365 implementations. The reason that this is bad is because Microsoft can go in and change these roles. You do not want their changes to affect your security configuration.
In Dynamics 365 Security Configuration is very easy to make copies of a role and have your own client copy. This way you can keep the original Microsoft role and also have a role that is an exact copy of the Microsoft role that you can make changes to.
This is also helpful when you want to compare a role to a Microsoft role.
Identify Segregation of Dutes and XDS requirements early
Another landmine that can come up in your Dynamics 365 project if you do not do discovery around security early is segregation of duties and Extensible Data Security (XDS).
Segregation of Duties allows a security administrator to identify privileges that conflict with each other. For example, you wouldn’t want someone to be able to create a sales order and receive a payment on a sales order. If a single person can do that it can be potential for fraud.
Extensible Data Security allows for filtering of records where you don’t want a user to see all the records in a particular table. For example, instead of seeing all vendors a user can only see vendors of a certain vendor group. Extensible data security allows you to set up this filtering.
Both of these features generally take a good bit of time to implement so you will want to start planning for them early. I always ask about these two areas during the discovery phase of my projects. This is another one where you really want to start as early as possible so you don’t end up delaying a go live because you do not have time to implement the correct segregation of duty rules or Extensible data security.
Conclusion
Dynamics 365 Security is one of those areas that is easy to forget about until the end of the project. At that point it is a mad dash to try and get it implemented correctly. The biggest takeaway I would like for everyone reading this is to start as early as possible with some sort of plan. Often I see that consultants don’t know where to start just start with what the client already has and try to build from there.