Workday resolves a worker's access from where they sit in the organisation, evaluated fresh every time. D365 F&O grants access directly to a user through a role assembled bottom-up from menu items, and that grant just sits there until someone edits it. This module maps every Workday security-group type, Domain Security Policy and Business Process Security Policy onto its D365 equivalent — including the one layer that has no equivalent at all — and covers Extensible Data Security, segregation of duties, licence cost and audit posture.
Every module so far in this domain has been about where something sits — a legal entity, an operating unit, a dimension value. This one is about who is allowed to see and change it, and it is the sharpest conceptual turn in the whole Workday-to-D365 path.
D365 F&O's authorisation model is a strict four-level hierarchy and, unlike Workday's policy layers authored against pre-existing functional Domains, is conventionally built bottom-up, starting from the concrete things a user clicks.
Configurable security mapping is a redesign risk, not a data-conversion task. Workday combines Domain Security Policies for data access with Business Process Security Policies for step participation, both bound to security groups that often derive from Supervisory Organization, role, company or worker attributes.
Read the four-level hierarchy again and notice what is missing: nothing in Role, Duty, Privilege or Entry point says anything about which specific document, at which specific step, gets routed to which specific person.
Role-based security answers a binary, object-level question: can this user see this menu item, field or table at all? It cannot answer a row-level question — "yes to Sales orders, but only the ones in Operating Unit 3." That is what Extensible Data Security (XDS) is for, and it is the nearest D365 gets to Workday's Constrained security…
Workday's reference material is candid that separating conflicting Domain and Business Process Security Policy grants is, in practice, a matter of administrative discipline — keeping certain permissions out of the same Security Group and periodically reviewing membership overlaps — rather than a rule engine that blocks a conflicting…
D365 F&O uses a named-user licensing model, and the security role a user is assigned is not just an access decision — it is the licence decision. Every entry point reachable through a user's duties and privileges, at its Read or Write access level, rolls up into a securable object breakdown: a per-role analysis of which named licence…
Workday customers arrive with an expectation that is, for the most part, correct on their existing platform: Business Process history, security and policy change history, and field-level change tracking on most Business Objects are present and queryable without a separate configuration step.
Workday's tight HCM-Finance coupling is a strength before migration and a risk afterwards. If Finance moves to D365 while Workday HCM remains authoritative, HcmWorker and HcmPosition are reference-only in the migration but still operationally important.
Workday resolves access from a worker's place in the organisation, re-evaluated continuously; D365 grants access directly to a user through a role assembled bottom-up from menu items that stays static until someone changes it. Every other difference in this chapter follows from that inversion.