Security roles in Dynamics 365 Sales

What it does

Dynamics 365 Sales ships a set of predefined Dataverse security roles that cover the usual sales shapes — seller, manager, VP — plus narrow functional roles for forecasting and sequences, plus app-access roles that simply let a user open a particular app. Everything a user can see or do is the union of the roles they hold, directly or through a team.

Key facts

The primary sales roles are Salesperson and Sales Manager (Sales Enterprise and Premium), Sales Professional Person and Sales Professional Manager (Sales Professional), and Vice President of Sales for cross-business-unit management.
Sales Manager adds product management, sales management, forecasting and goal management on top of the Salesperson privileges. VP of Sales is the same shape with wider scope.
Functional roles are separate and additive: Forecast Manager, Forecast User, and Sequence Manager. Sequence Manager only works alongside the Basic User role — on its own it does nothing useful.
App-access roles do exactly one thing: Sales, Enterprise app access (Sales Hub), Sales Professional app access, Sales team member (the Sales Team Member app). They grant app entry, not data privileges.
There are internal roles in the environment — Forecast Appuser, Sales system access and similar — that exist for platform components. Don't assign them to people and don't delete the AI agent application users the product creates.
Table privileges carry an access level: None, User, Business Unit, Parent: Child Business Unit, Organization. Higher levels absorb the lower ones.
Roles are cumulative. There is no deny. If a user holds two roles, the more permissive one wins for every privilege.
A custom role copied from a predefined role is a snapshot. When Microsoft updates the out-of-the-box role in a later release, your copy does not pick up the change.
Team-owned roles have two inheritance modes: team privileges only, or the default that also gives members direct User-level access so they can own records themselves.

When to use / skip

Every project uses these. The real decision is how far you drift from the predefined roles. Start by assigning the shipped roles and only build custom ones where a genuine requirement fails — usually restricting delete, restricting export to Excel, or narrowing Organization-level read on Account.

Copying Salesperson and hacking it "so we have our own" is the default instinct and it costs you every release. Prefer stacking: keep the predefined role for the baseline, add a small custom role holding only the deltas. That way the baseline keeps tracking Microsoft, your custom role stays small enough to review, and you can explain the security model on one slide.

Skip elaborate business unit structures unless ownership genuinely differs. Most "we need separation" requirements are satisfied by owner-level privileges plus a couple of teams.

Configuration decisions

Predefined roles as-is with additive custom deltas, or fully custom roles cloned from the originals — pick one approach and hold it for the whole project.
Business unit structure, because access levels only mean something relative to it, and restructuring later is painful.
Whether managers get access through role access levels, through hierarchy security, or through access teams. Pick one primary mechanism.
Who can export to Excel, print, bulk delete and run bulk edit — these are privacy and miscellaneous privileges that sit outside table permissions and are usually forgotten.
How roles are assigned: manually, by Microsoft Entra group teams, or by a provisioning process. Group teams scale better and are worth the setup on anything over a few hundred users.
Whether custom roles live in your solution and are deployed, or are managed directly in production.

Gotchas

Security roles do travel in solutions, but role assignments to users do not. A clean production deploy leaves everyone with no roles until someone assigns them.
Removing a role never revokes access granted by another role. Users complain they still see records; the cause is almost always a second role, often inherited from a team.
Sequence Manager without Basic User looks broken rather than unlicensed — the user sees the area but can't do the work.
Copying a role copies the privileges, not the future. Microsoft's changes to the source role in later waves never reach your copy, and the divergence only shows up when a new feature quietly fails for everyone except administrators.
App access roles are easy to miss: a user with full data privileges and no app access role simply doesn't see the app tile.
Organization-level read on core sales tables is handed out casually during UAT to make things work, and then never removed. Audit for it before go-live.

Consultant notes

Build a role matrix — persona down the side, table across the top, access level in the cell — and get it signed off before you configure anything. It's the artefact the client's security team will actually read.
Test with a real non-admin account in every environment. Testing as System Administrator proves nothing.
Push back hard on per-person roles. If the client asks for twelve variations of Salesperson, the requirement is usually field-level security or a couple of teams, not twelve roles.
Before go-live, list every user with System Administrator and make the client justify each one in writing.
Tell the client plainly that Dataverse security is additive with no deny. It reframes half their requirements before you've written a line of configuration.

Worth revisiting when Microsoft adds new predefined roles for agent or Copilot features, since those tend to arrive unassigned.