In enterprise D365 F&O deployments, security architects face a persistent governance challenge: role sprawl. As organisations scale, business requirements demand strict, localized data restrictions. The common but flawed response is to duplicate security roles based on organisational boundaries — starting with a standard AP Clerk role, then creating AP Clerk US, AP Clerk EU, AP Clerk Manufacturing.
Over time, this transforms a manageable security baseline of 50 roles into an unmaintainable web of hundreds of custom roles. This sprawl increases testing effort during updates, bloats SoD matrices, and complicates user provisioning. Extensible Data Security (XDS) provides the architectural alternative — row-level security from a single functional role.
What XDS Is and How It Works Architecturally
XDS is the native row-level security framework in D365 F&O. Unlike role-based security, which dictates application navigation, XDS dynamically filters the underlying data returned to the user interface.
Architecturally, XDS operates at the database layer. When a user queries a table protected by an active XDS policy, the system kernel intercepts the SQL statement and appends a pre-defined query range — a WHERE clause — before the request reaches the database. This is entirely transparent to the user: the application renders only the records the user is authorised to see.
The framework relies on three core AOT components: the Primary Table (the anchor entity), the Policy Query (the filtering logic), and Constrained Tables (related downstream tables that must also be filtered to maintain data integrity).
Three Distinct Security Layers — RBS, XDS, and TPF
These three layers are entirely independent. RBS filters navigation, XDS filters rows, and TPF filters columns. A complete security architecture requires understanding which layer governs which risk.
A Practical Example — Legal Entity Restriction Without Duplicate Roles
A standard AP Clerk needs access to the vendor master, but security policy mandates they can only view vendors assigned to their regional business unit. Natively, D365 F&O allows restricting a user's role to a specific single legal entity. However, when data restrictions must cross complex organisational hierarchies — or restrict data within a single shared company — standard company-context assignments fall short.
Instead of creating AP Clerk US, AP Clerk EU, and AP Clerk Manufacturing as three separate roles, an architect deploys one global AP Clerk role with an XDS policy. The policy query evaluates the logged-in user's organisational assignment dynamically. When the user navigates to All Vendors, the XDS framework intercepts the query and appends a range restricting output to vendors matching the user's authorised region. The user sees only their designated vendors. The IT Director maintains one role in the security repository — drastically reducing maintenance overhead and simplifying license management.
How to Configure a Basic XDS Policy
XDS policies are developed in Visual Studio and deployed via the AOT. Developer privileges are required.
Solution Explorer → Add New Item → Data Model → Query. Define the core data source and set the exact filter ranges that will restrict the data.Solution Explorer → Add New Item → Security → Security Policy.VendTable). Link the Query property to the AOT query from Step 1. Set Context Type to RoleName and specify the target security role.The Critical XDS Bypass — Data Entities and OData
This is one of the most dangerous misunderstandings in D365 F&O security architecture. Securing Data Entity access requires an entirely different mechanism — configuring separate integration mode privileges directly at the security role level, not through XDS.
To achieve true data containment, security architects must deploy a dual-layered approach:
- XDS policies — to restrict data at the application user interface layer
- Role-based integration mode privileges — to restrict Data Entity and OData access at the integration layer
Deploying only XDS without the integration layer leaves a bypass route that any user with basic technical knowledge can exploit — intentionally or not.
Common XDS Mistakes That Create Performance Issues
Poorly written XDS policies are a leading cause of severe performance degradation in D365 F&O. Because the XDS query is appended to every user transaction against constrained tables, inefficient logic scales disastrously.
Multi-level table joins: If an XDS query requires five table joins to determine a user's regional access, the system executes those joins for every row rendered on every form. This causes form load timeouts and database blocks at scale.
Unindexed high-volume tables: Applying XDS to high-volume tables like LedgerTrans or InventTrans without properly indexing the fields used in the query ranges forces full table scans on every user interaction.
TempDB tables in XDS queries: Using TempDB tables within an XDS query bypasses SQL Server caching mechanisms and forces heavy disk I/O operations — stalling the application kernel entirely.
When to Use XDS vs. When to Use Separate Roles
Never duplicate roles solely to achieve data filtering. That is exactly the problem XDS was designed to solve.
Closing Recommendation
Unchecked role sprawl creates unmanageable technical debt, complicates license optimisation, and obscures SoD violations. IT Directors and Security Architects must audit their D365 F&O security baselines to identify roles duplicated solely for data restriction purposes.
By replacing redundant roles with well-engineered XDS policies — and ensuring Data Entity integration mode privileges are independently secured — organisations can establish a lean, sustainable security architecture that drastically reduces testing overhead, simplifies audits, and maintains rigorous data governance.
A complete D365 F&O security architecture review — identifying role sprawl, XDS gaps, and integration layer vulnerabilities — delivered as a governance report within 48 hours. No system access required.