Seven chapters, seven separate building blocks. This capstone puts them all to work at once on a single small company, so you can see how a real access design actually gets assembled instead of staying seven disconnected ideas in your head.
The scenario: a two-department company
Picture a company with two departments, Sales and Support, that wants a sensible, minimal access setup: reps should mostly stay in their own lane, managers need visibility into their own team, a handful of accounts need shared ownership, one financial field is sensitive, and every so often someone needs into a record technically outside their normal area. That's enough variety to walk through everything in this course in one pass.
Step 1 — Business units
The environment's root business unit gets two child business units created under it: Sales and Support. Every rep is assigned to whichever one matches their actual job, giving the company the org-chart-shaped foundation the rest of the design builds on.
Step 2 — Security roles
A "Sales Rep" security role is created and assigned to everyone in Sales, granting Create, Read, and Write on the Opportunity table at the Business Unit access level. Reps should freely work Opportunities owned by anyone else in Sales, but there's no reason to see into Support's records — Business Unit level draws exactly that line, no extra configuration needed.
Step 3 — Hierarchy security for managers
Sales Managers hold the same "Sales Rep" role as their team, at the same Business Unit level — no wider. Turning on Manager Hierarchy gives each manager automatic read and limited-write access to their direct and indirect reports' Opportunities, based on the Manager field already set on every user record.
This is the right tool here because the need is narrow and automatic: a manager should see their own team's work, not the whole Sales business unit's, and not through a broader role that would blur that line.
Step 4 — An owner team for shared accounts
Not every account has a natural single owner — some regional accounts are worked collectively rather than by one rep. A "Regional Sales" owner team holds exactly those accounts, so they belong to the team rather than sitting unclaimed or arbitrarily assigned to one person. This is a job for an owner team, not a security role, because the need is genuine shared ownership of a batch of records, not a change to what any individual is generally allowed to do.
Step 5 — Field-level security for Credit Limit
The Account table carries a "Credit Limit" field that shouldn't be visible to most Sales reps. It's marked as a secured field, and a "Finance" field security profile is created with Read and Update permission on it, with only the finance team as members. Every rep can still open the Account record itself — their role and business unit already allow that — but Credit Limit shows blank to everyone outside the Finance profile.
Step 6 — Sharing a record one-off
A customer complaint requires a Support rep to look into a Case owned by someone in Sales, entirely outside their normal Support business unit. Rather than moving the rep into Sales or widening their role, the Case gets shared directly with them, granting Read and Write on just that one record.
Once the investigation wraps up, the share can be removed without touching the rep's role, business unit, or team memberships at all — nothing else about their access ever changed.
| Need | Mechanism used | Why it fit |
|---|---|---|
| Reps stay within their own department's records | Business units + Security role (Business Unit level) | General, ongoing scoping by org structure |
| Managers see their own team's records, not the whole department's | Hierarchy security (Manager Hierarchy) | Automatic reach into direct reports, without widening the role |
| Some accounts are worked collectively | Owner team | Genuine shared ownership across many records |
| One field is sensitive, rest of the record isn't | Field-level security | Precise, field-specific restriction |
| One person needs into one record, briefly, outside their normal scope | Sharing | Narrow, revocable, no lasting structural change |
Where to go from here
You've now covered the full set of access-control building blocks in Dynamics 365 CE. Two good next steps: the existing deep-dive tutorial D365 CRM Fundamentals & Configuration revisits security roles and sharing alongside the platform's broader configuration concepts. And if you want to go further into the Sales and Customer Service apps these security concepts sit underneath, a Core Modules course is also available in this learning path.