Every rollout has the meeting where somebody asks the question that security roles exist to answer: “wait — can the new intern see the CEO’s opportunities?” If nobody can answer confidently, the honest answer is usually yes. Dynamics 365 and Dataverse ship with a security model that is genuinely good, but it only protects you to the degree someone sat down and decided who sees what, and why. This post is that sit-down: how security roles are put together, what the five access levels really mean, and the habits that keep the model maintainable.
Why “just make them admin” is a debt, not a shortcut
The path of least resistance in every new environment is to hand out System Administrator until things work, and promise to tighten it later. Later rarely comes, and by the time it does, tightening means breaking workflows nobody documented. The platform’s model is worth learning precisely because it is cheap to get right at the start: a role is just a named bundle of permissions, and users can carry several of them at once — roles are additive, so you compose access out of small roles rather than sculpting one giant one.
Where the security model lives
The classic Settings → Security area is still the map of the whole territory: users, teams, business units, security roles, field security profiles — every piece of the “who can do what” story starts on this one page.
Two of these concepts do the heavy lifting together. Business units give your organization a shape — a hierarchy of departments or regions that records belong to through their owners. Security roles then grant permissions relative to that shape, which is what makes the model scale: the same “Salesperson” role means “your own patch” for a rep in Toronto and a rep in Sydney, without anyone maintaining two copies.
Reading a role: privileges × scope
Open a role — the built-in Salesperson is the best classroom — and every table gets a row of privileges: Create, Read, Write, Delete, Append, Append To, Assign, Share. The interesting part is not the verbs; it is the scope each verb is granted at:
Read this row aloud and you have a security policy in one sentence: a salesperson can create accounts (which then belong to them), read every account in the organization, but delete and assign only their own. That asymmetry — generous reading, stingy destroying — is the pattern almost every business wants and almost nobody writes down.
The five access levels, in plain words
- None — the verb does not exist for this user.
- User — only records they own (or that are shared with them).
- Business Unit — their own department’s records.
- Parent: Child Business Unit — their department and everything beneath it; the natural setting for managers of regions.
- Organization — everything, everywhere. Handy, and the level to challenge every time you see it on Write or Delete.
My rule of thumb when reviewing roles: Read wide, Write narrow, Delete narrower. Most collaboration problems are solved by widening Read; almost no business problem is solved by widening Delete.
Working habits that keep you out of trouble
- Never edit the built-in roles. Use Copy security role, rename the copy (“Salesperson — Contoso”), and adjust that. The originals stay as documentation of the defaults, and platform updates cannot surprise you.
- Assign roles to teams, not only users. A role granted to a team follows people as they join and leave it — onboarding becomes membership, not configuration.
- Test with a real test user. A user account with exactly the new role, nothing else, tells you the truth in two minutes. Your admin account tells you nothing — it can see everything by definition.
- Remember roles are additive. If a user has three roles, they enjoy the most generous level from any of them. A tight role cannot subtract what a loose one grants.
Wrapping up
Back to the meeting question: can the intern see the CEO’s opportunities? After an hour with the Salesperson row you can answer like a professional: “they can read them, because Read is organization-wide by design — but they cannot touch them, and here is the row that proves it.” Security roles reward exactly this kind of small, deliberate attention. Spend the hour; the alternative is spending it later, in the incident review.
