Dynamics 365 CE Interview Questions

Think of a security role like a keycard profile at an office building — instead of programming a different key for every door, you define a role like "Salesperson" that already opens the right set of doors, and then hand that one card to each new hire. A privilege, technically, is a single permission — Create, Read, Write, Delete, Append, Append To, Assign, or Share — on one specific table, and a security role is just a named bundle of those privileges. Administrators assign roles like "Salesperson" or "Case Manager" to users and teams instead of granting privileges one at a time, which is what makes access manageable at scale.

The four access levels work like keycard reach — does your badge open just your own office, your whole floor, your whole building, or every building the company owns? Dynamics 365 CE calls these Basic (User), Local (Business Unit), Deep (Parent-Child Business Units), and Global (Organization), and they control the scope of records a privilege applies to, not whether you have the privilege at all. A role with Write on Opportunity at Basic level only lets someone edit records they personally own, while the same Write privilege at Global level opens every opportunity in the company — in practice, it's this scope setting, not the privilege list, that usually explains why access ends up too broad or too narrow.

If someone is carrying two keycards, a security guard doesn't make them choose one — they get in anywhere either card allows. Dynamics 365 CE works the same way: effective privileges are the union of every role assigned directly to the user plus every role they inherit through team membership, and for any given privilege the platform always applies the most permissive access level across all of those roles. Roles are purely additive, so there's no way for one role to quietly cancel out or restrict a privilege granted by another.

This is basically the "your floor only" keycard scenario — each regional team should only reach its own area, with a master key reserved for the few people who genuinely need cross-region visibility. I'd model each region as its own business unit, or a child business unit under a shared parent, assign users to the business unit matching their region, and set the Opportunity privileges to Business Unit (Local) level on the sales role rather than Organization level. Regional managers who legitimately need to see across regions would get a separate role scoped to Parent-Child (Deep) or sit higher in the hierarchy, and a small cross-region support group is better handled with an owner team than by widening everyone's role.

If a table-level security role decides which rooms you're allowed into, field-level security is a locked drawer inside one of those rooms that needs a separate key even once you're standing in front of it. Security roles govern access at the record and table level — can this user see or edit an Opportunity at all — while field-level security is a narrower layer that only applies to fields explicitly marked as secured, controlling Read, Update, and Create on just that field regardless of what the table-level role otherwise allows. A user can have full Write access to a table through their role and still be blocked from one secured field until a field security profile is applied to them.

An owner team is like a shift crew that shares one set of keys and works a common queue together; an access team is more like a guest list added to one specific file so a handful of people can look at just that file. An owner team can own records directly, carries its own security roles, and every member inherits those privileges for as long as they're on the team — a good fit for a fixed group working a shared queue of records. An access team owns nothing and has no security role of its own; instead, an access team template hands out a fixed, predefined set of privileges automatically when someone is added to a record through a subgrid, which is the mechanism behind "add a collaborator" controls on a form.

This is like being allowed to walk into someone's office but not being allowed to write in their appointment book — being able to see a record doesn't automatically mean you're allowed to attach something new to it. Logging a phone call needs Append privilege on the Activity being created and Append To privilege on the Contact it's linking to; if either one is missing, the association silently fails even though the user can otherwise view and edit both records without any problem. Nine times out of ten, that's the gap to check first, not a Read permission issue.

Manual sharing is handing one specific person a spare key to one specific door, rather than reissuing everyone's keycard — it's fine as a one-off, but it doesn't scale as a policy. It fits a small, one-time need, like "these three people need access to this one record," because it grants a specific privilege subset on a single record without touching the broader role. Every shared record adds a row to the access table behind the scenes, so if the real requirement is "everyone in this role needs access to every record like this," that's a sign to redesign business units, teams, or the role's access level instead of sharing record by record.

A record's owning business unit works like a return address stamped on a package based on which office sent it — set automatically the moment it's created. It's normally inherited from the owning user or team at creation time, and it can be changed later by reassigning the record's owner or explicitly moving it, though doing that at scale, like reorganizing a business unit, can be an expensive operation since it recalculates security scoping across every affected record. Because business unit membership drives the Local and Deep access checks, moving a user to a different business unit changes what they can see immediately.

It's the same keycard-stacking idea again — trimming someone's personal badge doesn't help if they're also carrying a master key through a team they joined for an unrelated reason. Because roles are additive and can come from a role assigned directly to the user or from any team they belong to, a broad role attached to a team someone joined for an unrelated purpose still applies in full. Tightening the user's own role doesn't remove privileges granted through the team, so the real fix is usually to audit team memberships rather than keep shrinking the individual's role.

Think of it like a doorman with a guest list, comparing names before letting someone new in — either an exact match or a close-enough resemblance. A duplicate detection rule compares specified fields between records, using exact match or "similar" text matching, and can run at save time or as a scheduled bulk job. The catch is that a rule does nothing until it's explicitly published — it's common to find rules that were built and configured but never published, silently doing nothing during data entry.

It's the difference between checking IDs at the door versus doing a spot check on people already inside — catching a problem on the way in is far less disruptive than flagging someone after they're already settled. A rule can be configured to check on record create, record update, or both. Create-time checking stops obvious duplicates from entering through manual entry or import, while update-time checking is used more cautiously because it can surprise a user editing a legitimate existing record that now happens to look similar to something else, so many implementations only turn it on deliberately for specific fields.

I'd treat it like troubleshooting a smoke detector that isn't going off — first check whether it's actually switched on, then whether it's sensitive enough, then whether smoke is bypassing it entirely. First, I'd confirm the rule is actually published, since an unpublished rule silently does nothing. Second, I'd check whether the matching fields and match type really cover the real-world pattern of duplicates — an exact-match rule on email won't catch two records with a typo or different capitalization. Third, I'd check whether duplicates are entering through a path that skips the check altogether, such as a data import run with duplicate detection turned off.

An unmanaged solution is like a house that's still under renovation — anyone with access can keep changing it — while a managed solution is a house that's already been handed over and locked, where changes only happen through a formal new delivery. An unmanaged solution is fully editable in the environment it lives in and is the right container for active development; a managed solution is locked and can only be changed by importing a new version, which is the format used for test, UAT, and production. Uninstalling a managed solution removes everything it owns as a single unit, whereas unmanaged components can be deleted individually — which is exactly why you develop unmanaged and ship managed.

Solution layering works like stacking transparencies on an overhead projector — whichever sheet is on top is what you actually see, even though the sheets underneath still have their own markings. Each imported solution forms a layer, and if more than one layer customizes the same component, like the same form, Dataverse resolves the conflict per component using a top-layer-wins rule, not per solution as a whole. On a multi-team project where a base managed solution and a client-specific managed solution both touch the same table, a change one team makes can appear to do nothing simply because a layer imported later, or ordered above it, is winning for that particular component.

Customizing directly in the Default solution is like editing the master blueprint of an entire building instead of keeping a labeled set of change orders for one renovation — technically possible, but it makes it nearly impossible to tell later exactly what changed. The Default solution contains every customizable component in the environment, so exporting from it, or letting unrelated components sneak into a solution built from it, makes dependency tracking and clean deployment nearly impossible. Working inside a dedicated unmanaged solution with its own publisher prefix keeps the change set explicit, makes the export list predictable, and avoids shipping components you never intended to move.

Base currency is like the "home currency" printed on a company's master financial ledger — every other currency gets translated back into it for comparison, and you can't quietly rewrite the ledger's home currency after the fact. Base currency is set once, at organization creation, and every financial rollup and comparison in the system is ultimately expressed in it; transaction currencies are the additional currencies you configure, each carrying its own exchange rate against the base. Base currency can't be changed afterward because historical money values and exchange-rate snapshots throughout the system are anchored to it — changing it would silently invalidate the meaning of every amount already recorded.

It's like a receipt that shows the exchange rate on the day you actually paid — updating today's exchange rate doesn't rewrite yesterday's receipt. No, the exchange rate is captured and stored on the record at the time it's saved, so existing records keep the rate that applied when they were created or last saved in that currency. That's deliberate — it preserves what a historical opportunity or invoice was genuinely worth at the time, rather than letting old figures drift every time a rate updates; reports that need a current-rate view have to recalculate explicitly instead of relying on the stored value.

This is the standard sales funnel every sales org walks through, just with Dynamics 365 CE names attached — an unqualified prospect gradually turns into a paying customer through a series of clearly named stops. A Lead represents an unqualified prospect; qualifying it creates or links the Account/Contact records and typically an Opportunity, the active pursuit tracked through stages, usually via a Business Process Flow, ending in Won or Lost. A won Opportunity can generate a Quote with priced line items; an accepted Quote becomes an Order, a confirmed commitment to purchase, which can in turn generate an Invoice for billing.

Many companies already have a dedicated finance system that's their real cash register, so it makes little sense to build a second one inside the CRM. Most organizations already have a dedicated ERP or finance system of record for billing and invoicing, so extending that logic into Dynamics 365 CE would duplicate functionality and create a second source of truth for financial data. It's common to use Dynamics 365 CE purely as the pipeline and relationship system through Opportunity, then hand off to the ERP once a deal is won, without modeling Quote, Order, and Invoice at all.

Think of an Entitlement as the support plan a customer bought — how many tickets or hours they're owed — and the SLA as the stopwatch that starts ticking once a ticket comes in against that plan. A Case (Incident) is the unit of customer service work, typically routed through queues. An Entitlement defines how much support a customer is owed — a number of cases, a time window, or specific support hours — and has to apply before SLA logic engages. The SLA itself is built from SLA items, timers that measure something like time-to-first-response against a target, firing warning or failure actions if the case doesn't reach the matching status before the timer breaches.

It's the same idea as a company with a head office and semi-independent branch offices — branch staff get keys to their own branch, while head office holds a master key that reaches every branch without handing that same master key to everyone. I'd model each branch as its own business unit under a shared parent, so branch-level roles scoped to Business Unit (Local) access naturally isolate day-to-day data, while head-office roles scoped to Parent-Child (Deep) or Organization (Global) get cross-branch visibility without touching branch-level roles at all. For the specific records that genuinely need to cross branch boundaries, like a shared key account, I'd reach for an access team on that one record rather than widening anyone's role or business unit level.

A Business Process Flow is like the checklist a bank teller follows step by step with a customer sitting right in front of them; a workflow or Power Automate flow is more like the automated text message that goes out to that customer afterward without anyone having to press send. A Business Process Flow is a guided, stage-based UI element that walks a user through required steps and data on a single record, enforcing order without necessarily enforcing security. A workflow, or a Power Automate cloud flow layered on top, is background automation that runs without user interaction, such as sending a notification or updating related records when a stage changes — the two are often combined, with the BPF guiding data entry and the flow reacting to the stage transitions it produces.

This is the locked-drawer scenario again — finance doesn't need a different set of office keys, they just need one drawer in the shared office that only they can open. Rather than creating a separate finance-only security role that duplicates the sales role with different table-level access, I'd mark the specific fields, like margin or discount percentage, as secured and create a field security profile granting Read and Update to the finance team. That keeps the table-level role shared and simple while giving precise control over just the sensitive fields, which is exactly the scenario field-level security is designed for.