Ask any Dynamics 365 project team what keeps them up the week before go live and security roles will come up more often than you would expect. Not because the concept is difficult. It genuinely is not. It is because nobody wants to own the decision, so it gets pushed to the end of the project and then rushed by whoever is left in the room.
I have been the person cleaning up the result of that rush on more than one client site. Users with far more access than their job needs, roles nobody can explain, and a support queue full of "why can I see this" complaints. None of it is complicated to fix in principle. It just needs someone to think it through properly, ideally before go live rather than eighteen months after.
What Dynamics 365 security roles actually control
A security role is a collection of privileges applied per table, or entity if you still think in the old language. For each table you set a privilege level, read, write, create, delete, append, append to, assign and share, and an access level that determines the scope: none, user, business unit, parent child business units, or organisation wide.
That is the whole mechanism. The complexity comes from the fact that a real business has dozens of tables, each needing a different combination of privilege and access level for each type of user. Multiply that out across sales, customer service, finance and any custom tables you have built, and you can see why teams reach for shortcuts.
The shortcut everyone reaches for, and why it bites you later
The most common shortcut is copying the out of box System Customizer role, or worse, System Administrator, and handing it to power users because "they need to do a bit of everything." It solves the immediate problem in the short term. It also means those users can now delete records, change business rules and see data that has nothing to do with their job. When something goes wrong six months later, you have no way of narrowing down who could have caused it, because half the organisation has admin level access.
I understand why teams do this under deadline pressure. It is genuinely faster to grant broad access than work out the precise privileges a role needs. The problem is that fixing it later, once real users are relying on that access day to day, is a far bigger job than getting it right during implementation.
Model roles around job function, not the org chart
The single biggest mistake I see is building security roles that mirror the company org chart rather than what people actually do in the system. A "Sales Manager" role and a "Regional Sales Manager" role that differ only by one field is not a security model, it is a naming exercise that will confuse whoever inherits the system after you.
Instead, think in terms of function: what does this group of users need to read, what do they need to create or edit, and what should they never be able to touch. A field sales rep, an account manager and a sales director are all "sales" in the org chart, but they need meaningfully different levels of access to pricing, discounting and pipeline visibility. Build roles around that distinction, not the reporting line.
Use business units properly, or do not use them at all
Business units are one of the most misunderstood parts of the Dynamics 365 security model. Teams either ignore them entirely, leaving everyone in one flat business unit, or they build an elaborate hierarchy that mirrors the legal entity structure and then wonder why record ownership and reporting behave strangely.
My rule of thumb is that business units should reflect how data actually needs to be segmented for security purposes, not how the company is structured on paper. If two divisions never need to see each other's records, a business unit split makes sense. If you find yourself building complex sharing rules to work around business unit boundaries, that is a sign the boundaries were drawn in the wrong place.
Practical steps to get security roles right
Start restrictive and open up, not the other way round. It is far easier to grant a user more access when they hit a genuine wall than to claw back access they have been relying on for months.
Keep the number of custom roles as small as you sensibly can. Every additional role is another thing to maintain, test and explain to the next person who works on the system. If you find yourself with twenty near identical roles that differ by one privilege each, you have a maintenance problem waiting to happen.
Test with real user impersonation before go live, not just with your own admin account. It is astonishing how many issues only surface when you actually log in as the restricted user and try to do their job. This should be a formal part of your go live checklist, not an afterthought squeezed in on the last day.
Document why each role exists and what it is meant to allow. This sounds tedious and it is, but it is the difference between a security model someone can maintain in three years and one that gets treated as a black box nobody dares touch.
Do not forget field level security
Table level privileges are only half the picture. Field security profiles let you restrict specific fields, salary information, national insurance numbers, sensitive contract terms, regardless of what the security role otherwise allows. Teams often build a solid security role model and then forget field security entirely, leaving sensitive fields visible to anyone who can see the record.
The two systems work independently and both need thinking through together. A role can grant full read access to a table while field security profiles still lock down the fields that genuinely need protecting.
Where this fits into a wider implementation
Security roles are rarely the headline feature of a Dynamics 365 project, and that is exactly why they get neglected. Nobody demos security roles to the steering committee. But a poorly designed security model causes more day to day friction than almost anything else, and it is one of the more expensive things to fix once live, alongside the kind of costly mistakes I have written about before.
If you are scoping a new implementation, build security role design into the plan from the start rather than treating it as configuration you can knock out in a couple of days near the end. It does not take long to do properly if you start early enough, and it saves a huge amount of pain later.
Every organisation I have worked with that got this right did the same thing: they treated security roles as a design exercise involving the business, not a technical task for the implementation partner to sort out unsupervised. Sketch out the roles on a whiteboard with people who understand how the business works before you touch the platform.
If you are working through a Dynamics 365 implementation and want an independent set of eyes on your security model, or on the wider architecture, that is exactly the kind of work I do as a Technical Architect. Getting it right early is always cheaper than fixing it once people are relying on the system.
