Think of Dynamics 365 CE (Microsoft's customer relationship management platform, often just called "D365" or "the CRM") as an office building, not a single room. Before any custom software gets built inside it, someone has to decide who gets which keys, how the floors are laid out, and how information is shared between departments. Get those basic decisions wrong early on, and you spend the rest of the project fighting them — people who can see things they shouldn't, or can't see things they need. Get them right, and a lot of what sounds like "custom development" in a project plan turns out to be simple configuration, no coding required. This tutorial walks through the building blocks I rely on most, explained the way I'd explain them to someone who has never opened Dynamics 365 before.
Security roles and the role hierarchy
A security role is simply a bundle of permissions. Think of it like an employee keycard at a large office building. Every keycard can be programmed with a set of doors it opens — the supply closet, the break room, the server room — and Dynamics 365 works the same way, except the "doors" are actions on records: Create, Read, Write (edit), Delete, Append, Append To, Assign, and Share.
It's not enough to say "this keycard opens the Accounts door" — you also have to say how far it reaches: just the cardholder's own desk, their whole floor (business unit), the building including smaller floors reporting up to theirs, or every building the company owns. Two roles can both say "Read: Account" and behave completely differently depending on that reach. Microsoft calls these levels Basic, Local, Deep, and Global — "just mine," "my floor," "my floor and below," and "the whole company."
Nobody designs a keycard from a blank sheet of paper. You start from one of the ready-made badges Microsoft ships (Salesperson, Customer Service Representative, System Administrator, and so on), copy the closest match, then add or remove a few doors — avoiding the classic mistake of a badge that quietly can't open a door someone actually needs, like the ability to search records or leave a note.
One more rule worth remembering: badges only add access, they never take it away. If someone carries two keycards, they can open every door either one opens — you can't hand them a second badge to lock a door the first already unlocked. If a person ends up with more access than intended, the fix is almost always "take away a badge" (or take them off a team — more below), never "give them a stricter one."
Why this matters on a project
A mistake in security design isn't just a bug — it can mean the wrong person can see or change data they were never supposed to touch. I've seen a go-live delayed because a "read-only" badge quietly inherited edit access to a financial record through a team nobody remembered assigning. Treat the access map as a living document from day one, not something sorted out the week before launch.
Business units, owner teams, and access teams
A business unit is the floor plan the keycard reach above is built around. Every person and every record lives on exactly one floor at a time. Most companies match the org chart — a floor per region or division — but some split floors by function instead, like "Sales," "Service," and "Back Office," when that fits how access actually needs to be carved up.
Teams are where a lot of real-world sharing happens, and there are two genuinely different kinds:
- Owner teams work like a permanent desk. The team itself can own records, just like a person can, and you assign it a security role the way you'd badge an employee — everyone on the team inherits that access for as long as they stay a member. Use one when a fixed group works a shared pile of records together, day in and day out.
- Access teams work more like a shared project room you get added to temporarily. They don't own anything and carry no security role of their own. Instead, a template says "anyone added to this specific record gets Read/Write/Append on it," and that access appears the moment someone is added — usually through an "add a team member" list on the record's own form — and disappears the moment they're removed.
Rule of thumb: an ongoing group with a standing job → owner team. Ad-hoc helpers on one record, added and removed by everyday users → access team.
Record sharing and how far your keycard reaches
Sometimes a badge and a floor plan aren't enough — you need to hand one specific record to one specific person, outside whatever their normal badge allows. That's manual sharing: granting a user or team a slice of permissions (Read, Write, Append, Append To, Assign, Share) on exactly one record, regardless of their assigned role.
Two of those permissions confuse almost everyone the first time they see them:
- Append — the right to attach this record onto something else. Think "can I clip my note onto that folder."
- Append To — the right to have other things attached onto this record. Think "can other people clip their notes onto my folder."
So if someone needs to log a phone call against a Contact, they need Append on the call and Append To on the Contact. In troubleshooting, "the user can see the contact but can't log a call against it" is nearly always this exact pairing, not a missing Read permission.
Sharing is handy but gets expensive if overused — every shared record adds an entry the system checks on every access, and sharing thousands of records one at a time is a well-known way to slow things down. "These five people need this one record" is a fine use of manual sharing; "everyone in this role needs every record like this" is really a floor plan or owner team question in disguise.
Duplicate detection rules
Picture a bouncer at a door checking ID so the same guest doesn't get let in twice under two slightly different spellings of their name — "Jon Smith" versus "John Smith," say. That's exactly what a duplicate detection rule does for your data: it compares fields like name, email, or phone using rules you configure — an exact match, or "close enough" matching for text — and can check either the moment someone hits save, or in a scheduled batch job scanning everything already in the system.
A detail that catches people out: a rule has to be explicitly switched on ("published") before it does anything, and it only checks the entities and moments (create, update, or both) you've told it to. It's common to find a rule that was carefully built but never switched on, quietly doing nothing — worth checking during a data quality review.
Solutions: shipping your customizations
A solution is the shipping container for everything you customize in Dynamics 365 — new fields, forms, views, automation, and more. There are two flavors, and the difference is a lot like buying a sealed, factory-packaged product versus a kit of raw parts you can still rework:
| Unmanaged (the kit of parts) | Managed (the sealed product) |
|---|---|
| You can open it up and edit pieces directly | Locked — the only way to change it is to ship a new version |
| Used while actively building and testing | Used once things move to test, sign-off, and live environments |
| You can remove one part without removing the rest | Uninstalling takes the whole package out at once |
| The base layer — nothing sits underneath it | Can have another package installed on top of it, layering further changes |
That last row confuses people who've only worked solo. When a sealed (managed) package is installed, it becomes a layer. If a second package — or someone's unsealed customization — later changes the very same thing, like the same form, Dynamics 365 decides which layer's version shows up, piece by piece, not package by package: whatever's on top wins, for each thing touched. This matters most when a vendor's product and a company's own customizations both reach into the same area, and a change someone swears they made doesn't seem to appear anywhere — because a layer above it is winning.
Base currency vs. transaction currency
Every Dynamics 365 environment has exactly one home currency, chosen at setup and never changed afterward. Any other currency you configure alongside it is a "transaction currency," each with its own exchange rate against the home currency. Every money field on a record keeps a snapshot: the currency it was entered in, and the exchange rate that applied at that exact moment — like a photograph taken at the time of the sale. That snapshot matters, because an old deal's recorded value doesn't quietly change just because today's exchange rate has moved.
This becomes a real conversation on projects spanning multiple countries: does leadership want the whole sales pipeline converted at today's rate, or should each deal keep the rate that applied when it actually happened? Reporting needs usually answer that question — worth asking directly rather than guessing.
The standard sales process: from lead to order
Out of the box, Dynamics 365 models a fairly straightforward sales funnel, not unlike how a shop might track someone from "just browsing" to "paid and delivered":
- Lead — someone who might be interested, but isn't yet a confirmed customer contact in the system.
- Qualify — converting a Lead creates (or links to) a real Account and/or Contact, and usually an Opportunity to track the deal.
- Opportunity — the active deal, moved through stages (think of a visual checklist) toward Won or Lost.
- Quote — a formal, still-changeable proposal with prices and line items.
- Order — created once the quote is accepted; a confirmed "yes, we're buying this."
- Invoice — the bill, generated from the order, handing off to finance.
Most companies don't use this whole chain as shipped — it's common to stop at Opportunity and hand everything after "we won the deal" off to a separate finance or ERP system (enterprise resource planning — the back-office accounting system), using Dynamics 365 purely to track the relationship and the pipeline. Figuring out which parts of this flow a company actually needs is one of the first decisions on a sales-side project.
Customer service basics: cases and SLAs
The Case (sometimes called "Incident") is the basic unit of work in Dynamics 365's customer service tools: one customer problem, tracked from the moment it's logged to the moment it's resolved, usually sitting in a queue until it's picked up or assigned automatically. An SLA (service level agreement — a promise about how fast you'll respond) works like a kitchen timer attached to that case: it measures something like "time to first response" against a target, and if the timer runs out first, a warning or escalation fires — often a notification straight to a manager.
SLAs are usually paired with entitlements, which describe how much support a customer is actually owed — a number of cases, a time window, or specific support hours — before the timer logic even starts. On paper this looks like a small settings screen; in practice, getting the timer to correctly pause overnight and resume correctly when a case changes status is one of the fiddlier parts of a service desk project, and deserves its own round of testing rather than being checked only in passing.
Field-level security: locking a single field, not a whole record
Sometimes a whole record is fine for someone to see, but one field on it isn't — a salary, a national ID number, a negotiated discount. Field-level security handles exactly that, separately from the keycard-style role system above. You mark a specific custom field as "secured," then define a profile saying who can read, edit, or set that one field. Anyone not covered doesn't just get a greyed-out box — the value is hidden completely, missing from forms and lists alike. It's the right tool for a genuinely sensitive field here and there; it's overkill if you reach for it on every field a role merely shouldn't casually edit, where a well-designed form is simpler and easier to maintain.