✏️ Explanatory Question

Explain the role-based security model in Dynamics 365 Finance & Operations. What are roles, duties, privileges and permissions, how do they relate, and what is the purpose of Extensible Data Security (XDS)?

👁 1 Views
📘 Detailed Answer
🟢 Easy
No previous question
No next question
💡

Answer with Explanation

D365 F&O • X++ INTERVIEW

Security in Dynamics 365 Finance & Operations: Roles, Duties, Privileges & XDS

Question 16 — The role-based security hierarchy and Extensible Data Security for row-level control.

Interview Question

Explain the role-based security model in Dynamics 365 Finance & Operations. What are roles, duties, privileges and permissions, how do they relate, and what is the purpose of Extensible Data Security (XDS)?

Model Answer (Short)

D365 F&O uses a hierarchical, role-based security model. A user is assigned one or more roles (e.g. Accountant); each role contains duties (a business task like "maintain customer payments"); each duty groups privileges (access to run a specific function); and each privilege bundles individual permissions on objects (menu items, tables, fields, service operations) with an access level such as Read, Update, Create or Delete. On top of this, Extensible Data Security (XDS) restricts which rows a user can see using query-based policies — for example limiting a user to records for one business unit. Security should be developed as source-controlled objects, not just configured in the UI.

The Security Hierarchy

From role down to permission

  • Role — a collection of duties mapped to a job function. Users are assigned roles, ideally automatically via rules.
  • Duty — a group of privileges representing a business task or responsibility (supports segregation of duties).
  • Privilege — grants access to run a specific function/feature; contains the underlying permissions.
  • Permission — the lowest level: access to a specific securable object (menu item, table, field, service) at a given access level.
HIERARCHY
User → Role → Duty → Privilege → Permission

Access levels & effective access

  • Access levels follow an increasing order: No Access → Read → Update → Create → Correction → Delete.
  • A user's effective access is the maximum granted across all their assigned roles.
  • Access is granted through entry points (menu items, form controls, service operations).

Extensible Data Security (XDS)

Row-level security with policies

  • XDS restricts which records (rows) a user can access, not just which objects.
  • A policy is built from a constrained table, a policy query, and a context (e.g. based on the user or a role).
  • Filtering happens at the database query level, so it applies consistently everywhere the table is read.
  • Because policies add query constraints, they can affect performance — keep the relationship between the primary and constrained tables efficient and indexed.

Development best practices

  • Develop roles, duties and privileges as objects and keep them under source control.
  • Use the D365 security configuration UI only for temporary adjustments.
  • Design for segregation of duties to avoid conflicting responsibilities.
  • Use XDS for data-level restrictions instead of hard-coding filters in business logic.

Prerequisites (Rule 5)

  • Visual Studio with the Dynamics 365 developer tools.
  • A custom model / package for your security objects.
  • Securable objects (menu items, tables) already created for the privileges to reference.
  • For XDS: a constrained table, a policy query, and a context table/role.

Code Example — Checking permission in X++

Verify a user has the required access before running sensitive logic:

// Check access to a menu item entry point
if (hasMenuItemAccess(menuItemActionStr(AbcPostInvoice), MenuItemType::Action))
{
    // User is allowed to run this action
}

// Check table-level permission
if (hasTablePermission(tableNum(AbcOrderHeader), AccessType::Delete))
{
    // User can delete records in this table
}

Applying an XDS policy context in code

// Set the application context so an XDS policy can read a role/value
XDSServices xdsServices = new XDSServices();

// Example: enable a policy that filters by the current worker's business unit
xdsServices.setXDSContext(
    curUserId(),
    /* contextString */ "BusinessUnitContext");

Reading the current user & roles

UserId          currentUser = curUserId();
SecurityRole    role;
SecurityUserRole userRole;

while select RoleIdentifier from userRole
    where userRole.User == currentUser
    join role
        where role.RecId == userRole.SecurityRole
{
    info(strFmt("Assigned role: %1", role.Name));
}

Points the interviewer wants to hear

  • Hierarchy: User → Role → Duty → Privilege → Permission.
  • Effective access is the maximum across all assigned roles.
  • XDS adds row-level security via query-based policies.
  • Security objects should be source-controlled, not just UI-configured.
  • XDS policies can impact performance — design the constrained relation carefully.

Likely Follow-up Questions

  • What is segregation of duties and how does D365 enforce it?
  • How does effective access work when two roles grant different levels?
  • What are the components of an XDS policy?
  • Why should security be developed as objects rather than configured only in the UI?

Key Takeaway

D365 F&O security flows top-down through Role → Duty → Privilege → Permission, granting the maximum access across a user's roles. Layer XDS policies on top for row-level control, and always build security as source-controlled objects for consistency and auditability.

D365 F&O Interview Series — Question 16 of many
No previous question
No next question