How the two security systems inside EBS — function security through responsibilities, menus and functions, and data security through objects, instance sets and grants — land on D365's bottom-up role, duty, privilege and entry point hierarchy, plus Extensible Data Security, native segregation of duties and the licence tier that role design quietly writes.
The organisational chapter for this path settled what each ledger, legal entity, operating unit and inventory organization becomes. This chapter is about who is allowed to touch the result, and how a programme proves it to somebody who audits for a living.
It is worth separating the two EBS systems explicitly before mapping either, because migration teams routinely fold them together and then cannot explain why one restriction moved to the assignment layer and another moved to a policy.
D365 composes four levels above the entry points they secure, and the composition runs upward from objects the application already contains rather than downward from a written access matrix.
Three EBS objects carry function security, and each maps with a different amount of friction.
Data security is the EBS system that maps most cleanly in concept and least cleanly in mechanics.
An estate that invested in Role Based Access Control and delegated administration will feel three specific losses, and it is better to name them in design than to discover them in user acceptance testing.
EBS has no delivered engine that blocks a conflicting combination of access at the moment somebody creates it. Segregation of duties in an EBS estate is a responsibility-design convention, enforced by review, sometimes checked after the fact by a third-party governance product.
In EBS, responsibility design and licence position are two separate conversations that meet at a true-up. In D365 they are the same conversation, continuously.
An EBS estate arrives with two sets of expectations, and they land in two different places.
The single most consequential decision in this workstream is what the design starts from. Starting from the responsibility export produces a D365 role set carrying all of EBS's accumulated complexity and none of D365's simplifications, because the export describes objects shaped by upgrades, reorganisations, one-off projects and…
Consider a responsibility that lets a payables clerk enter and match supplier invoices but never release a payment. Its menu is a delivered payables menu with the payment-batch functions excluded.
EBS carries two security systems and D365 keeps the separation while changing both mechanisms. Function security — responsibility, menu, function — becomes a bottom-up hierarchy of entry point, permission, privilege, duty and role, generated from what the application already exposes rather than declared from an access matrix.