How SAP's PFCG roles, authorization objects, SU24 proposals and GRC Access Control map onto D365's bottom-up role → duty → privilege → entry point hierarchy, Extensible Data Security and native segregation of duties — and the licensing and auditing consequences of getting role design wrong.
Part 1 of this domain mapped the skeleton — legal entities, sites, warehouses and the financial dimensions that carry the rest of the enterprise structure. This chapter is about who is allowed to touch that skeleton, and how you prove it.
D365 security composes four levels — permission, privilege, duty and role — above the entry points they secure, and — unlike PFCG, where an architect typically starts by naming a role and adding transactions to its menu — the hierarchy is generated from the bottom up, starting from objects that already exist in the application.
PFCG's three role types exist to solve three different problems, and each maps onto the D365 hierarchy with a different amount of friction.
Role-based security answers "can this user use this function." Extensible Data Security (XDS) answers a different question entirely: "which rows can this user see through it." That split does not exist in SAP, where an org-level authorization field does both jobs inside one object.
D365 ships a genuine segregation-of-duties engine — a real but much lighter control than GRC, not no control at all.
Every entry point a role can reach carries a licence-entitlement tag against the named Dynamics 365 subscriptions — Finance, Supply Chain Management, Commerce, Human Resources, Team Members and Activity — at the access level (Read or Write) the role grants.
D365's native audit surface is narrower than what a SAP team typically expects from change documents and table logging.
The single biggest mistake in migration security design is starting from the legacy PFCG role export. That export describes forty or four hundred roles shaped by years of SAP-specific accretion — org-level derivation, one-off Z-transaction bundles, historical reorganisations nobody cleaned up — and porting that shape produces a D365 role…
Consider a composite role, Z_AP_CLERK_COMPOSITE, bundling two single roles: Z_AP_INVOICE_ENTRY (menu: FB60, FB65, MIRO; authorization objects including F_BKPF_BUK with BUKRS as an organisational-level field) and Z_AP_PAYMENT_BLOCK (menu: FB02, FBL1N;
D365 replaces PFCG's role-centric, field-value-driven model with a bottom-up hierarchy — entry point, permission, privilege, duty, role — generated from what the application already exposes rather than declared from an authorization matrix. Composite and single roles collapse into ordinary role design;