I’m starting a new series of articles dedicated to security modeling in Dynamics 365 Customer Engagement.
The aim is to go beyond the basic principles that are already detailed in Customization and Configuration courses or on TechNet.
I will provide design tips, best practice and examples to simplify a CRM security model implementation and administration.
Why is it crucial to address the security model early in a project?
- The Dynamics 365 Customer Engagement security model is powerful and flexible: it offers many options that can be combined.
- It must be addressed right from the start of your project, because chances are it will impact your data model and business rules.
- You must always have in mind your security model, in particular when you design business processes or complex data models (e.g. business processes encompassing several entities, or entities with child records…)
Security model design Golden Rules
- Have the future in mind: think about the administration effort when you will have to configure hundreds of users.
- Keep it simple: at some point, new people will have to understand it and make it evolve.
- Don’t sweep things under the carpet: it might be tempting to not address a potential security issue, but it’s best to spend time on it while you are designing your model rather than wait for users to notice it in production.
- Negotiate: opinions can change on how strict or complex the security model should be!
- Share: educate your customer on how the standard security model works and what different options it offers, it will then be easier to try to fit in.
- Differentiate: are we talking about filtering what we see, or restricting access to data? Sometimes a filtered view is just what you need.
- Scalability and performance: your model might work well for a few users, business units and records. How would it scale for hundreds of thousands / millions?
The different security model options and how you should address them