Unit4 access and attribute security vs D365 roles, duties and Extensible Data Security

How Unit4's flexible Role, Access Right and Attribute Value security-domain model collapses into D365's fixed role-duty-privilege-entry-point hierarchy and Extensible Data Security, why that flexibility does not survive the move unchanged, and what a public-sector-grade audit trail and licence-aware role design actually require.

What you will be able to do

Introduction

Part 1 traced Unit4's organisational model down to the Attribute Value, closing with a mapping table in which one decision driver kept reappearing: security policy. Attribute Values destined to carry access restrictions become Operating Units; the rest become Financial Dimensions.

The D365 security hierarchy: role, duty, privilege, entry point

D365 F&O's security model is a strict four-layer hierarchy, and unlike almost everything else in this migration, the direction of construction matters as much as the shape.

Unit4's role, access right and attribute-based security model

Unit4's access model is built the other way around, and the difference is not merely cosmetic.

Extensible Data Security: policies, constrained tables and honest limits

Extensible Data Security (XDS) is D365's only native, general-purpose row-level security framework, and it is built from four components.

Segregation of duties: rules, conflicts and overrides

Where Unit4 typically treats segregation of duties as a manual review exercise — someone periodically reads the Role and Access Right matrix and flags anything that looks wrong — D365 ships an automated conflict-detection engine, configured at System administration > Security > Segregation of duties.

Licence implications: how role design drives cost

D365's named-user licensing is keyed to the security model, not a headcount category — which catches Unit4 architects off guard, since Unit4 licensing, broadly a named user per Client, does not penalise a broad role the same way.

Auditing: database log, security reports and public-sector expectations

Unit4 customers in Unit4's core market — public sector, higher education, not-for-profit — arrive with a non-negotiable expectation: a complete, exportable record of who changed what, who approved it, and who was allowed conflicting duties and why.

A practical role-design method for the migration

The single most reliable way to under-deliver a D365 security design is to start from the Unit4 role export. Unit4 roles accumulate historically, often named after a person, a department or a one-off exception, encoding years of individual trust decisions rather than a business process.

Worked example: converting a Unit4 attribute-restricted role

Take a realistic example: a local-government Unit4 customer has a Regional Finance Officer role whose Access Rights allow invoice entry, receipt allocation and read-only budget reporting.

Knowledge check

Summary

Unit4's access model puts the real intelligence on the Attribute Value — a security domain that cascades through a hierarchy and can be reshaped by an administrator at any time.