Security, segregation of duties and access control

How D365's role, duty, privilege and entry point hierarchy — generated bottom-up from real menu-item usage — replaces IFS's permission-set-on-projection model, and what Extensible Data Security, segregation-of-duties rules and licence-tiered roles mean for a migration that is tempted to copy permission sets instead of redesigning access around the business process.

What you will be able to do

• Explain the D365 role, duty, privilege and entry point hierarchy and why it is generated bottom-up from recorded menu-item usage
• Map IFS permission sets, projections and End User access to D365 roles, duties and Extensible Data Security policies
• Configure a segregation-of-duties rule and describe the override and compensating-control workflow
• Assess the licence-cost impact of a role design before it goes live
• Apply a business-process-first method to convert one IFS permission set into a D365 role

Introduction

Part 1 of this domain, Enterprise Structure and Organisational Model, established how IFS's Company, Site, Warehouse and Location become D365's Legal Entity, Site, Warehouse and Financial Dimension.

The role, duty, privilege and entry point hierarchy

D365 F&O security is strictly hierarchical, and every layer exists for a specific administrative reason.

From IFS permission sets and projections to D365 roles

IFS grants access through a Permission Set: a named bundle of Full Access, Read-Only or Custom rights over one or more Projections, the OData/REST-shaped views that expose a Logical Unit's operations to the Aurena and Touch App clients.

Row-level security: legal entities, sites and Extensible Data Security

Assigning a Role in D365 has a genuine, native legal-entity scope: an administrator assigns a role to a user either for all legal entities or for specific legal entities, directly on the assignment. This is the closest thing D365 has to IFS's per-user allowed Company list, and unlike XDS it requires no development;

Segregation of duties: rules, conflicts and overrides

Most IFS estates control segregation of duties by review: someone periodically reads the Permission Set assignments and judges, by eye, whether one person can both request and approve the same payment. D365 replaces that review with a configured rule engine.

Licence consequences of role design

D365 F&O licenses by named user, using Base plus Attach sequencing across product lines — Finance, Supply Chain Management, Commerce, Human Resources, Project Operations — plus two lighter tiers, Team Members (very light, largely self-service tasks shared across the whole Dynamics 365 family) and Operations - Activity (light operational…

Audit trail and database logging versus IFS history

IFS keeps field-level change history at the Logical Unit level: LU history configuration drives rows into *_HIST shadow tables, coordinated through LOGICAL_UNIT_HISTORY_TAB, giving a before-and-after trail keyed to the LU regardless of which screen made the change.

A practical role-design method, worked end to end

The single most common and most costly implementation mistake is designing D365 roles from the legacy IFS permission-set list. Permission Sets are organised around what a Projection exposes, a system-centric grouping. Duties are supposed to be organised around what a business process needs, a process-centric grouping.

Knowledge check

Summary

D365 shapes access around a Role, Duty, Privilege, Entry point hierarchy generated from what people actually do, scopes legal-entity access at the point of assignment, and prices licences off whatever a role can reach — all genuinely different mechanics from IFS's Permission-Set-on-Projection model with its Company/Site-scoped End User…