The Access Setting That Silently Opens Every Company in Your Group

D365 treats a user-role assignment that carries no organization rows as access to all legal entities. Ship one unscoped assignment in a deployment package and you have widened access across the whole company without anyone deciding to.

In an add-only deployment package, the core roles were scoped correctly, but the add-on roles and the restriction carriers shipped with no organization rows at all. In D365 that is not "scoped to nothing." It is "scoped to everything." Every user who received one of those add-ons would have been granted its access in every legal entity in the tenant, regardless of where they actually work.

The default is all, not none

When you assign a security role to a user in D365, you can attach organization scoping (the legal entities where that assignment applies). If you attach nothing, D365 does not fall back to an empty scope. It falls back to the full organization.

This is the opposite of the safe default most people expect. An empty list usually means "none." Here it means "all." So the dangerous case is not a mistake you make while scoping. It is the scoping you forget to do. A forgotten scope is a silent grant to every entity.

Why this is a security problem, not a licensing footnote

It is tempting to file this under licensing, because wider access can mean more billable footprint. That undersells it. Legal-entity scope is a containment boundary. Finance users in one subsidiary are not supposed to see, post to, or edit another subsidiary's data. An unscoped assignment erases that boundary for everyone who holds the assignment.

The people most affected are exactly the ones you would least want over-scoped. Add-ons tend to carry the sharper, task-specific capabilities (posting, approvals, master-data edits), and restriction carriers exist specifically to shape what a user can and cannot touch. Shipping those global is how a user scoped to one company ends up able to act in twenty.

And it is invisible in the usual places. The user still shows the roles everyone expects. The assignment looks normal. What changed is a scope that was never populated, which no access report that lists roles will flag.

The scoping discipline for a safe package

A package that only adds roles still has to say, for every single assignment it ships, which legal entities that assignment applies to. The rule that held up in practice:

• - Core roles take the scope the user already has for the scaffolding role they are built from. A core is sourced from a single original role, so its contents are a subset of that role's grants, and that role's existing scope is the right boundary.
• - Add-ons and restriction carriers, under an add-only policy, take the union of the scopes of the keys being delivered that are themselves scoped. You scope the add-on to exactly the entities its scoped contents need, and no wider.
• - A key the user already holds globally through a retained original role stays global on its own. That is fine, because it is access the user already has. The important consequence is the reverse: an already-global key must never be allowed to force the add-on itself global, because that would widen every other, properly scoped key riding on the same add-on.

The package also ships a per-assignment widening report, so a human can see exactly which assignments changed scope and confirm none of them widened access by accident. Scoping is a decision that gets reviewed, not a default that gets trusted.

Bottom line

In D365, "no scope" means "every legal entity," so every assignment in a package is a scoping decision whether you make it or not. Scope cores from the originating role, scope add-ons and carriers to the union of their scoped contents, never let a globally-held key drag an add-on global, and ship a widening report so the choice is auditable. Treat an unscoped assignment as a defect, not a default.

Frequently asked questions