M3 security and segregation of duties: from function-and-programme authority to D365's role, duty and privilege model
How D365 F&O's role -> duty -> privilege -> entry point hierarchy, generated bottom-up from menu items, replaces M3's function-and-programme authority and CONO/DIVI/warehouse scoping, and why role design now also drives licence cost and audit posture.
What you will be able to do
Explain the D365 role -> duty -> privilege -> entry point hierarchy and why it is generated bottom-up rather than declared top-down
Map M3's user, function, programme and related-option authority onto the corresponding D365 security objects, and identify where M3 is coarser and where it is finer
Design an Extensible Data Security policy that reproduces the restriction M3 delivered through CONO, DIVI and warehouse scoping
Configure segregation-of-duties rules and the override workflow, and explain what changes from M3's largely manual controls
Assess how a security role's duty and privilege composition drives Finance, SCM, Activity and Team Member licence counts
Convert one M3 authority profile into a D365 role, duty set and XDS policy using a repeatable, process-first method
Introduction
M3 administrators reason about access in terms of what a sign-on can reach: which companies (CONO), which divisions (DIVI), which programmes, and which numbered options on each panel -- a coarse-grained, largely manual model built up one authority record at a time and rarely revisited.
The D365 security hierarchy: role, duty, privilege and entry point
D365 F&O's security model has four layers and, unlike most legacy authority models including M3's, it is assembled bottom-up rather than declared top-down.
M3's authority model: user, function, programme, and the CONO/DIVI/warehouse boundary
M3's access model has no bottom-up generation step -- an administrator declares authority against objects that already exist, layering Function authority, Programme-level overrides, and related-option toggles.
Extensible Data Security versus CONO, DIVI and warehouse restriction
Where M3 restricts data through hard keys -- CONO and DIVI as literal primary-key columns on almost every table, WHLO the same for inventory tables -- D365 has no equivalent structural partition below the legal entity. A role with general ledger access can read every division's postings unless something explicitly stops it.
Segregation of duties: from manual control to enforced conflict detection
M3 has no native concept of a segregation-of-duties conflict. Nothing stops an administrator granting one user both "maintain vendor bank account details" and "approve vendor payments" -- a textbook SoD violation.
Licensing: how role design becomes a cost model
M3 licence cost is set by seat type -- named or concurrent user -- largely independent of what authority that seat holds. A named user with Full access to every Function and one restricted to a single Display-only programme typically cost the same.
Auditing and change visibility
M3 administrators are used to a shallow but universal audit trail: almost every table carries RGDT/RGTM (registration date/time) and LMDT/LMTS (last-maintenance date/timestamp), plus CHNO and CHID identifying the change number and the user who made it.
A practical role-design method for the migration
The most common mistake here is treating security as a data-conversion problem: extract every user's M3 authority, find the closest-named D365 object for each Function and Programme, and assign it. This reliably produces bloated, expensive, SoD-non-compliant roles that inherit every accumulated exception in the legacy authority list.
Knowledge check
Summary
D365 F&O replaces M3's function-and-programme authority, related-option toggles, and CONO/DIVI/warehouse scoping with a four-level hierarchy -- role, duty, privilege, entry point -- generated bottom-up from the objects developers build, not declared top-down.