How D365 F&O's role -> duty -> privilege -> entry point security model, Extensible Data Security, and native segregation-of-duties rules replace Infor LN's authorization templates, DEM roles, and company/table-level authorization — and what licence tiers and audit expectations change along the way.
Part 1 of this domain resolved LN's Logistic Company and Financial Company model into D365 legal entities, sites, and dimensions. This chapter resolves a different, equally consequential question: who is allowed to do what, where, and how do you prove it.
Every D365 security object is one of four types, and each is composed entirely from the layer below it.
LN's classic access model layers four constructs, most of which predate any formal business-process modelling:
Legal-entity-scoped role assignment reproduces LN's company authorization, but stops at the company boundary. LN administrators regularly need a finer cut inside one Financial Company — an Enterprise Unit-level restriction, so a regional buyer sees only their region's purchase orders despite sharing one Financial Company.
LN has no native rule engine for segregation of duties. Keeping incompatible responsibilities apart — the same person should not both maintain a vendor's bank details and release that vendor's payment — is a manual authorization-design discipline in LN, enforced by review or by a third-party GRC product bolted onto the landscape for…
LN authorization design carried no software-licence consequence — a broader authorization cost nothing extra to assign. D365 uses a named-user licensing model tying roles, duties, and privileges directly to licence requirements — one of the sharpest differences a migration programme will feel in its budget, not just its access model.
LN's audit expectations are usually satisfied implicitly: a DEM audit log on Business Object state transitions, module-specific history tables (order history, item history), and printed or archived documents for statutory review.
The single most consequential decision in an LN-to-D365 security programme is the design method, not the first draft role list. Designing from the legacy authorization list guarantees importing legacy sprawl, SoD conflicts, and over-privileging.
Consider an LN "Purchasing Officer" DEM role, expressed as an authorization we will call AUTH-PUR-OFF (illustrative naming — verify exact session and table names against the source environment):
D365's security model inverts LN's: instead of a flat authorization cloned from a DEM role and layered with company and table/field grants, access is compiled bottom-up from the application's own menu items, forms, and service operations, then organised into entry points, privileges, duties, and roles.