2.2 Permission Sets & Security Group Management

Permission Sets & Security Group Management

Security in Dynamics 365 Business Central is built upon an object-oriented permission model that safeguards database records and controls code execution. Functional consultants must know how to design, customize, and assign permissions efficiently using modern governance techniques, such as Microsoft Entra ID Security Groups and permission recording, while adhering to core accounting principles.

---

The RIMDX Permission Architecture & Object Types

Every functional feature in Business Central corresponds to one or more underlying application objects. Security permissions govern whether a user can interact with these objects:

• TableData: The actual data records stored inside a database table (e.g., TableData 18 Customer, TableData 17 G/L Entry).
• Table: The architectural table definition and schema metadata.
• Page: User interface displays (cards, lists, worksheets, role centers).
• Codeunit: Business logic containers executing background posting routines, validations, and automated processes.
• Report & XMLport: Data extraction, printable layouts, and structured file import/export tools.
• Query: High-performance multi-table data extraction structures.
• System: Core platform-level system actions and security operations.

The RIMDX Access Rights

Permissions evaluate user rights across five distinct operations, collectively designated as RIMDX:

• Read (R): Rights to view records within a TableData object.
• Insert (I): Rights to add and commit new records into a TableData object.
• Modify (M): Rights to edit existing field values within records in a TableData object.
• Delete (D): Rights to permanently remove records from a TableData object.
• Execute (X): Rights to run runnable objects: Page, Codeunit, Report, XMLport, Query, or System operations.

Direct vs. Indirect Permissions

For each RIMD operation on a TableData object, an administrator specifies either Yes (Direct) or Indirect:

• Yes (Direct): The user is granted direct access to perform the action through the user interface, APIs, or worksheets. For example, setting Modify = Yes on TableData 18 Customer allows an order processor to open a customer card and update the address or phone number.
• Indirect: The user cannot perform the operation directly. However, if they execute an authorized runnable object (such as a posting codeunit) that has been granted elevated permissions in its AL code, the operation succeeds.

The Transactional Integrity Principle

Indirect permissions are fundamental to financial compliance and the double-entry accounting integrity of Business Central. In financial ledgers, users must never be permitted to directly insert, edit, or delete records. Allowing direct edits would corrupt the audit trail and break financial reconciliations.

Consider TableData 17 (G/L Entry):

• Users are assigned Read = Yes, allowing them to view financial history and run trial balance reports.
• Users are assigned Insert = Indirect, Modify = Indirect, and Delete = No.

When an accountant posts a General Journal, they execute Codeunit 12 (Gen. Jnl.-Post Line). Codeunit 12 possesses embedded AL code permissions to insert records into TableData 17. Because the user holds Indirect insert rights, Codeunit 12 successfully creates the posted ledger entry. If the user attempts to edit or insert a record into G/L Entry directly via a page or import, the system blocks the action immediately.

---

Types of Permission Sets: System, Extension, and User-Defined

Permissions are grouped into Permission Sets displayed on the Permission Sets list page (Page 9802). Business Central classifies permission sets into three architectural categories:

1. System Permission Sets:
   • Built directly into the core platform by Microsoft (e.g., D365 BUS PREMIUM, SECURITY, LOGIN).
   • Indicated by Type = System.
   • Completely Immutable: Administrators cannot edit, add, or delete individual permission lines, nor can they delete the permission set itself.
2. Extension Permission Sets:
   • Supplied by first-party or third-party AppSource extensions or per-tenant extensions (PTEs).
   • Indicated by Type = Extension.
   • Immutable in the UI: Controlled entirely by the extension's AL code. When an extension is updated, its permission sets update automatically.
3. User-Defined Permission Sets:
   • Created by system administrators within the Business Central web client.
   • Indicated by Type = User-Defined.
   • Fully Mutable: Administrators can add objects, remove lines, adjust RIMDX levels, configure security filters, or delete the set entirely.

Modifying Built-in Permissions via Copying

Because System and Extension permission sets cannot be modified directly, administrators follow a standard duplication pattern when custom permissions are required:

1. Open Tell Me (Alt+Q) and search for Permission Sets (Page 9802).
2. Highlight the System or Extension permission set to customize (e.g., D365 SALES, EDIT).
3. Select Actions -> Copy Permission Set.
4. In the dialog, provide a New Permission Set Name (e.g., CUSTOM-SALES-RESTRICTED) and a descriptive label.
5. Business Central duplicates all object lines into a new User-Defined permission set.
6. Open the newly created set, select Permissions, and adjust the lines—for example, changing Delete from Yes to No on TableData 36 (Sales Header) and TableData 37 (Sales Line).
7. Assign the User-Defined permission set to the appropriate security group or user, and remove the original System permission set.

Exclude Permissions

In User-Defined permission sets, administrators can explicitly set the Permission column to Exclude. If a user is assigned a broad permission set granting access to all setup tables, an administrator can assign a second permission set that explicitly excludes TableData 98 (General Ledger Setup), ensuring the user cannot alter core financial configurations even if granted broad rights elsewhere.

---

Recording Permissions: Capturing Workflows Automatically

Business Central consists of thousands of database tables, temporary buffer tables, and execution codeunits. Manually identifying every object required to execute a specific business process is error-prone. Missing a single temporary buffer table will cause runtime permission errors when users attempt to complete transactions.

To eliminate guesswork, Business Central provides the Record Permissions tool:

1. Create or open a User-Defined permission set and navigate to its Permissions subpage.
2. On the action bar, choose Record Permissions -> Start.
3. A notification confirms that permission recording has commenced.
4. Without closing the web client, navigate to the target business process (e.g., create a Purchase Order, receive lines, and post the invoice).
5. Execute only the exact steps required for that workflow. Avoid opening unrelated pages or menu items, as every touched object will be captured in the recording buffer.
6. Return to the Permission Set card and select Record Permissions -> Stop.
7. The system prompts: "Do you want to add the recorded permissions to the permission set?" Select Yes.
8. Review the newly added rows. Convert any direct Insert or Modify permissions on ledger tables to Indirect to preserve transactional posting rules.

---

Security Groups and Microsoft Entra ID Integration

Managing security assignments on an individual user basis creates administrative overhead and compliance risks. Modern Business Central deployments use Security Groups integrated directly with Microsoft Entra ID.

Architecture of Security Groups

1. Upstream Group Creation: An IT administrator creates a Security Group in the Microsoft 365 Admin Center or Microsoft Entra ID (e.g., SG_BC_AccountsPayable) and adds employee accounts to it.
2. Mapping in Business Central:
   • Navigate to Tell Me -> Security Groups (Page 9860).
   • Select New to create a group record.
   • Enter a Code and Name.
   • In the Microsoft Entra Security Group ID field, select the corresponding Entra ID group using the lookup picker.
3. Assigning Permission Sets to the Security Group:
   • Highlight the security group and choose Permissions.
   • Assign the required Permission Sets (e.g., D365 PURCH, EDIT, LOCAL).
4. Dynamic Permission Inheritance:
   • When a user logs in, Business Central evaluates their Entra ID group memberships. If they belong to SG_BC_AccountsPayable, they automatically inherit all permission sets linked to that Security Group.
   • If an employee transfers to another department, IT updates their Entra ID group. Business Central permissions update automatically on the next login, eliminating manual ERP user maintenance.

---

Multi-Company Permission Scoping

In multi-company Business Central environments, users often require different levels of access across different legal entities:

• A regional controller might need full posting permissions in Cronus USA Inc., but only read-only rights in Cronus UK Ltd..
• A warehouse operator might only need access to a single distribution entity.

This segregation is managed using the Company Name field on the User Permission Sets page or Security Group Permission Sets page:

• Blank Company Name: If the Company Name column is left blank, the assigned permission set applies across all companies currently existing in the environment and any new companies created in the future.
• Specific Company Name: If an administrator selects a specific company from the lookup, the permissions granted by that row apply exclusively when the user operates within that designated company.

Multi-Company Configuration Matrix

---

Common Pitfalls & Exam Gotchas

• Granting Direct Ledger Access: Granting Insert = Yes on TableData 17 (G/L Entry) or TableData 21 (Cust. Ledger Entry) in a custom permission set creates an audit violation. Ledger permissions should always be Indirect.
• Directly Editing System Permission Sets: An exam question might ask how to remove delete rights from D365 SALES, EDIT. Candidates must remember that System sets are read-only; you must copy the set to a User-Defined set first.
• The Global SUPER Danger: The built-in SUPER permission set grants full access to all objects and bypasses all security filters. If assigned with a blank Company Name, the user has unconstrained administrative power across every company in the tenant.
• Unintended Tenant-Wide Scoping: When assigning permissions intended for a single operational subsidiary, forgetting to populate the Company Name field unintentionally grants those rights across all companies in the tenant.