Category: Business CentralRead time: 7 MinsPublished on: 13 Feb 2026

Business Central Permissions Sets: Complete Guide to RIMDX, Security Filters & Role-Based Access

  1. Home
  2. Blog
  3. A Complete Guide to Business Central Permissions Sets

1. What is Business Central Permissions?

Business Central permissions are RIMDX-based access rules that determine who can read, insert, modify, delete, or execute objects such as pages, tables, reports, APIs, and code units, governed through permission sets, security filters, Entra ID identities, and licensing boundaries.

One over-privileged user can inadvertently destroy your whole financial integrity or cause a very expensive compliance violation. Most companies find it hard to walk between operational agility and security. How do you give your people access to the data they need without letting them change things at sensitive tables?

This is where Business Central Permissions Sets become your most strategic asset. Much more than a simple "on-off" switch for access to the system, these sets are detailed blueprints that define exactly which records a user can read, insert, modify, or delete. Moving from personal user assignments to a structured role-based security model lets you apply the Principle of Least Privilege with surgical precision.

This guide will discuss what permissions in Business Central are, how to manage them, and audit them to protect your data while keeping daily tasks easy.

Organizations designing least-privilege access often struggle to translate job roles into technical RIMDX rules, security filters, and Entra ID mappings. Our Business Central consulting services help businesses define permission sets, segregation-of-duties models, and secure API access without disrupting daily operations.

2. Understanding Business Central Permissions

The permissions framework in Microsoft Dynamics 365 Business Central defines what users can see, modify, and execute across the system. It ensures controlled access to business data and operations. In contrast to simple role-based tools, Business Central permissions work on multiple levels of application and data, including user interface actions, application objects, system tables, and record-level permissions.

This model allows administrators to align security with job functions, compliance requirements, and segregation-of-duties principles while supporting integrations, automation, and external access scenarios. To understand how Business Central enforces access and control, it helps to break down the security model into key aspects:

  1. How the Business Central security model works:
    • Permission sets are used to assign permissions, which are defined as follows: Read, Insert, Modify, Delete, Execute.
    • Permission sets may be standard (supplied by Microsoft), system-generated, or custom-built.
    • The permissions are granted to the users by assigning them either directly to security groups or by assigning them one or more permission sets.
    • The data visibility can also be limited, but object access remains the same, using security filters.
    • Licensing defines capability boundaries that permission cannot override.
  2. Layers of security: UI, objects, tables, and data:
    • UI Layer: Determines the visibility of pages, actions, and menus within the client interface.
    • Object Layer: Controls the access to application objects, which include pages, reports, code units, XML ports, as well as queries.
    • Table and Field Layer: Manages CRUD access to system and application tables, with some having field-level rules.
    • Data Layer: Imposes record-level filtering using security filters to restrict access by a user to rows within a table.
  3. Roles of users, permissions, and security policies:
    • Users: Represent individuals or service accounts that authenticate into environments.
    • Permission Sets: Collections of objects and table permissions defining what tasks a role can perform.
    • Security Groups & Azure AD Integration: Enabling the proficiency to map organizational roles to Business Central roles on scale.
    • Security Policies: Strengthening other restrictions, including record filtering, segregation of duties, and environment-specific restrictions.

3. Permission Sets Explained

Permission sets in Microsoft Dynamics 365 Business Central are used to determine the precise actions that a user is permitted to perform in the application. A permission set is simply an organized group of object-level and table-level permissions. These permissions regulate access to and write access to business entities (e.g., customers, sales orders, and items), execution of access to application objects (e.g., reports and code units), and communication with external interfaces (e.g., APIs and web services).

Permission sets are designed with the main purpose of offering a modular, reusable security abstraction that is sensitive to job responsibility and that ensures compliance and governance standards. Business Central implements access control using granular types of permissions, which are known as Read, Insert, Modify, Delete, and Execute (RIMDX).

  • Read (R): Allows viewing data (e.g., customers, inventory, ledger entries) without modification.
  • Insert (I): Allows creating new records (e.g., creating sales orders).
  • Modify (M): Allows editing existing records (e.g., updating customer addresses).
  • Delete (D): Allows removing records (often restricted in financial modules).
  • Execute (X): Allows running application objects such as reports, pages, XML ports, queries, and code units.

Permission sets can be provided by Microsoft (standard), auto-generated by the system, or manually created by administrators (custom).

  • Standard permission sets cover core functional areas of sales, purchasing, finance, and warehouse. They are all included in standard permission sets, enabling rapid onboarding of common job roles.
  • System-generated permission sets are created automatically during testing or extension development to represent the necessary access according to the actions of the user.
  • Custom permission sets allow organizations to customize permissions to compliance requirements, segregation-of-duty requirements, or job roles that are a combination of job requirements.

Permission sets may be assigned to the user once they have been created or inherited by the users via the security groups of the Azure Active Directory (AAD). It allows centralized user provisioning and deprovisioning. Business Central also supports layered assignment, allowing users to accumulate permissions from multiple sets, which is critical for hybrid responsibilities such as “Sales + Service” or “Warehouse + Production.” This is a scalable and secure user access structure which does not require configuration of redundancy across environments.

Standard permission sets frequently used in Dynamics 365 Business Central include D365 BUS FULL ACCESS, D365 AUTOMATION, SECURITY, and TEAM MEMBER sets. Administrators often combine these with custom Business Central permission sets examples created via the Permission Set Recorder to meet segregation-of-duties and compliance requirements.

4. Common Questions about Business Central Permissions

  • How to create permission sets in Business Central?
    Use Permission Set Recorder → perform user actions → convert captured objects into a custom set.
  • What is RIMDX in Business Central permissions?
    RIMDX stands for Read, Insert, Modify, Delete, Execute—the core access model.
  • How to restrict data by salesperson in Business Central?
    Apply Security Filter: Customer. “Salesperson Code" = 'SP01'.
  • How to fix “You do not have the following permissions” error?
    Add missing EXECUTE on page/code unit or RIM rights on the related table.

5. Managing Permissions at Scale

Managing permissions in enterprise deployments requires structured governance rather than ad hoc user assignments. Business Central aids this using a Role-Based Access Control (RBAC) model, where access is assigned to roles or functions and not to a specific user. RBAC permission sets are based on job functions (e.g., Accounts Payable Clerk, Warehouse Operator, Service Manager), and users have the security profile of their job, which greatly eases the administrative load.

Enterprises implementing RBAC across multi-company environments often require structured role design and testing. Engaging Business Central consulting services ensures permission inheritance, Entra security group mapping, and SoD compliance are implemented correctly.

Organizations often design their roles using either functional role design or cross-functional role design:

  • Functional roles: Assign permissions to one domain of responsibility (e.g., AP Clerk, Sales Order Processor).
    Cross-functional jobs: Support hybrid jobs which need authorizations in more than one area (e.g., Sales + Warehouse Coordination).
  • Security and separation-of-duty compliance are enhanced with the help of functional roles, whereas the friction in smaller teams is decreased with the help of cross-functional roles.

Business Central support’s role templates, security groups, and patterns of inheritance of permissions to scale role management to many users. It is possible to map Azure AD security groups into Business Central roles so that users can be onboard and offboard automatically based on the management of corporate identities. Permission inheritance enables intricate role hierarchies with no replication of configurations, which is especially handy for organizations that have stratified responsibility structures (e.g., Clerk → Supervisor → Manager).

At the enterprise level, permissions must also account for multi-company and multi-environment scenarios. Multi-company deployments may require either shared roles across companies (e.g., centralized finance) or segregated roles (e.g., independent local operations).

6. Record-Level Security

Microsoft Dynamics 365 Business Central has record-level security. It determines the specific records that a user is permitted to view, modify, or act on within a given allowed table. Whereas permission sets are used to control access on an object and table level, record-level policies are used to regulate visibility and operations on a row level.

The model is necessary in organizations with multi-company, multi-department, or limited financial conditions, whereby the users are only supposed to view their own customers, vendors, warehouses, dimensions, projects, or business units. Security filters, company isolation, and dimension-based controls are used to enforce record-level security. It does not require core processes to be redesigned or unnecessary permission fragmentation to be created.

Here is how record-level security operates in Business Central:

  1. How does record-level filtering work?
    • Enforced at query/execution time to filter returned dataset
    • Uses Security Filters to restrict allowed values (example: "Customer”. “Salesperson Code" = 'SP01'")
    • Applied on queries, pages, API calls, and reports
  2. Company-level isolation
    • Business Central considers the company as a firm demarcation.
    • Access to specific companies should be given to the users explicitly.
    • Cross-company access to data is prohibited unless it is integrated through APIs or a data warehouse.
  3. Dimension-based visibility controls
    • Global Dimensions, Shortcut Dimensions, or Responsibility Centers can be used to filter financial and operational data.
    • Common use cases:
      • Department-specific GL visibility
      • Isolation of sales data on a regional basis.
      • Financial reporting on a project basis.
  4. Security filter scenarios

    Typical business scenarios leveraging record-level security include:

    • Sales reps only accessing customers they own
    • Service technicians see only assigned service orders
    • Branch managers are limited to their warehouse inventory
    • Project accountants see only the project/Job entries they support
  5. Record-level control limitations
    • Security filters cannot be applied to all objects (not supported for all table types)
    • Filters minimize the visible information, but nothing is changed in posting or transactions.
    • The improper testing of over-filtering may result in blank reports or API payloads that have been missed.

7. Environment Administration

In Microsoft Dynamics 365 Business Central, environment administration determines the behavior of permissions in a sandbox and production environment, with respect to backups, restores, updates, and deployment events. Access to the environment is controlled by Admin Center and Entra ID (previously Azure AD), whereas the management of users, permissions, and isolation at the company level is handled by Business Central within the environment. This division makes sure that security policies do not change, even when developers are testing extensions, automating workflows, or migrating data.

Here is how environmental administration affects permissions:

  1. Environment boundaries
    • Every environment (Production, Sandbox) is segregated.
    • There should be explicit access per environment for the users.
    • Applications and automation should be approved separately.
  2. Company isolation
    • Every company within an environment has its access controls.
    • Users must be assigned to one or multiple companies.
    • Posting, reporting, and master data are not shared across companies.
  3. Admin Center vs. internal security
    • Admin Center = who can access the environment
    • Business Central = what they can do inside it
    • Entra ID = identity + authentication
  4. Lifecycle events

    Permissions must be validated after:

    • Major updates (permissions can be modified depending on new objects).
    • App or extension deployments (EXECUTE needed by new tables and code units).
    • Environment clone (“Sandbox from Production” replicates permissions)
    • Data migrations (mappings may break security filters)
  5. Backup & restore considerations
    • Restored environments do not automatically inherit Admin Center assignments
    • Integration credentials must be revalidated after restoring
    • Web services and OAuth tokens must be refreshed for security compliance

8. Permissions for Integrations and Automation

Integrations in Business Central rely on explicit permissions to allow external systems, such as Power Automate, API clients, EDI, ISVs, or legacy connectors to read or write data. These integrations often require object-level EXECUTE permissions for system objects (code units, pages, query objects) in addition to table permissions. OAuth (Entra ID) app registrations define identity, while permission sets define authorization, creating a secure and governed automation surface.

Here is how permissions interact with Business Central integration:

  1. API & web service access
    • API users require EXECUTE on API pages/queries
    • Table permissions must allow Read/Insert/Modify/Delete
    • Standard sets: D365 Automation, D365 Bus Full Access, etc.
  2. Service principals & OAuth apps
    • Non-interactive logins use Entra ID App Registrations
    • Must map Application ID to a Business Central user
    • Used for EDI, Power Automate, scheduling, and custom middleware
  3. Power Automate & Logic Apps
    • Use delegated permissions tied to the signed-in identity
    • Require both:
      • Business Central permission sets
      • Entra ID API rights (user impersonation)
  4. On-premises or hybrid connectors

    • Use Basic Auth or OAuth
    • Require Web Service Access Key for legacy scenarios (being deprecated)
    • Need API Endpoint or ODBC/SQL permissions, depending on architecture
  5. Common automation failures

    Caused by missing:

    • EXECUTE on code units
    • MODIFY/INSERT on target tables
    • Automation or System object permissions
    • Environment-level permissions
  6. Required Permissions by Scenario
    Scenario Needed Permissions
    API Integration EXECUTE on API pages + RIM on tables
    Financial Posting INSERT + MODIFY on G/L tables
    Read-only reporting READ on tables + EXECUTE on reports
    Power Automate D365 Automation set + Entra user impersonation

9. Troubleshooting Permission Issues

The troubleshooting of Business Central permissions involves studying the execution of objects, access to tables, the restriction of data by security filters, and the response of API calls. Since failure happens during the execution and not during the login, users may seem to have access until a certain action is performed, which results in permission denial. Permission Set Recorder, Event Viewer, Telemetry, and AL error logs are some of the tools that can give the execution trail required to isolate failing objects.

Here is how to diagnose permission problems:

Error → Cause → Fix

  • 403 Forbidden → Missing permission set → Add EXECUTE on page/code unit
  • Blank report → Security filter too restrictive → Review record filter
  • 401 Unauthorized → Entra/OAuth issue → Revalidate identity
  • 404 → Wrong API object → Verify endpoint name
  1. Symptoms of permission failures
    • “You do not have the following permissions…”
    • Reports rendering partially or blank
    • APIs returning 403 Forbidden or 401 Unauthorized
    • Pages loading without editable controls
    • Extensions failing during upgrade (EXECUTE missing)
  2. Diagnostic tools

    Effective built-in tools include:

    • Permission Recorder (captures object calls during user actions)
    • Session Event Viewer (logs runtime object access)
    • Telemetry in Azure (extension + API instrumentation)
    • AL Debugger (for developers analyzing code unit paths)
  3. Root cause categories

    Most permission issues fall under:

    • Missing EXECUTE on code units/pages
    • Missing table data RIMD rights (Read/Insert/Modify/Delete)
    • Security Filters hiding expected records
    • Company access is missing in specific environments
    • Integration user lacking automation/system object access
  4. API troubleshooting

    For integration failures:

    • 401 = authentication failure (Entra ID / OAuth issue)
    • 403 = authorization failure (permissions issue)
    • 404 = incorrect endpoint or object name
    • 429 = throttling or rate limits
  5. Resolution strategies

    Admin teams typically:

    • Re-play actions with Permission Recorder
    • Create custom permission sets from captured actions
    • Test in sandbox with least privileged principles
    • Promote production using AL or Permission Sets export/import

10. Licensing and Permissions

Licensing is used to determine who has the right to access Business Central and at what level of functionality. On the other hand, permissions are used to establish what can be done by those licensed users within the system. Permission restrictions, role assignments, or company access restrictions may block the user even with the right license.

On the other hand, broad permissions are not a substitute for license restrictions, since some application areas (e.g., manufacturing or service management) need license levels to enable object access. In the case of integrations and automation, service principal authentication by non-interactive licensing can be mandatory to prevent the use of named user licenses.

Here are the key licensing considerations for Business Central permissions:

  1. User license types
    • Premium: Full function footprint with Manufacturing + Service modules.
    • Essentials: Basic financial, sales, purchasing, stock, and warehouse.
    • Team Members: Team members have limited read/write access (no posting, no heavy modules).
    • Device License: Shared use of the device in warehouse, FIFO, or point-of-sale applications.
  2. Non-interactive / Automation licensing
    • Non-Interactive Service Account: For headless integrations (one per tenant)
    • Service Principal Access: Requires Entra ID application + BC user mapping
    • Power Automate Robotics: May require attended/unattended add-ons
  3. Feature access by license

    Some features are license-bound, for example:

    • Manufacturing → Premium
    • Service Management → Premium
    • Basic Warehouse (Bins, Picks) → Essentials
    • Advanced Warehouse (Directed Put-Away/Pick) → Essentials + Config
  4. Licensing vs. permissions boundaries
    • Licensing = entitlement
    • Permissions = enforcement
    • Entra ID = authentication
    • Environmental access = Admin Center governance

11. How to Assign and Review Permissions?

Assigning and reviewing permissions in Business Central is not merely a security exercise, but a governance process. Here is how permissions are assigned and reviewed in a controlled manner:

Step 1: User assignment workflow

  • Use Business Central in Microsoft Entra ID and provision.
  • Enter license type (Essentials, Premium, Team Member, etc.).
  • Grant permission sets based on functional role (e.g., Accountant, Warehouse, AP Clerk)
  • Optionally set company assignments and environment (Production/Sandbox) limitations
  • Validate role operation via permission test sessions or Permission Recorder

Step 2: Evaluating existing permissions

  • Use User Card → Effective Permissions to see aggregated access
  • Analyze table/object access through Permission Set → Permissions tab
  • Review Security Filters for record-level constraints
  • Track permission denials through Telemetry logs or event messaging.

Step 3: Periodic access reviews and audits

  • Conduct quarterly or semi-annual access reviews for:
    • Posting and approval of financial positions.
    • Warehouse and production planning.
    • Integration service accounts
  • Validate compliance with least-privilege and segregation-of-duties (SoD) standards
  • Certify changes in regulated industries (SOX/ISO) by using audit trails.

Step 4: Identifying unused or excessive permissions

  • Identify idle or dormant roles based on the comparison of the login or activity logs.
  • Eliminate role-based permissions on departure or change of roles.
  • Determine the presence of over-privileged accounts with:
    • Excess table access (POST, MODIFY, DELETE)
    • Global configuration access
    • Cross-company or cross-environment access
  • Reassign users from custom one-off sets to standardized RBAC roles

12. Best Practices Checklist

Here are the best practices to ensure secure and scalable permission management in Business Central:

  1. Adopt Role-Based Access Control (RBAC)

    Permission limits should be set depending on job functions and not on individual users. This prevents access models that are fragmented and that provide uniformity across departments. The end users are not supposed to be given direct permission on tables or objects. Also, functional permission sets are supposed to include all the permissions that a certain role needs.

  2. Use Least Privilege Principles

    Permissions should be granted strictly on a need-to-execute basis, ensuring users receive only the minimum access required to perform their tasks. The least privileged models minimize the surface risk and make audits easier. Periodic reviews can be used to determine the unused privileges that have been added due to promotions, transfers, or onboarding changes.

  3. Separate Duties for Compliance

    Compliance-driven environments benefit from separating financial posting, approval, and configuration activities across different roles. This helps in the common regulatory frameworks like SOX, ISO, and ITGC, avoids conflicting access patterns, and safeguards the integrity of finances by avoiding end-to-end execution by an individual user.

  4. Use Permission Set Recorder for Accuracy

    The Permission Recorder should be used to capture required permission objects by replaying real user tasks inside Business Central. This guarantees that new permission sets are based on realistic execution paths as opposed to assumptions. The output recorded can be cleaned and transformed into reusable permission sets that can be used in an enterprise.

  5. Manage Permissions at Scale

    Templated and standardized permission bundles simplify the process of onboarding and provide the same access across different companies. In the case of multi-entity or distributed environments, AL packages or Admin API tooling can be used to export, version, and deploy permissions, allowing scalable governance and alignment of DevOps.

  6. Validate Environment Boundaries

    Organizations should continuously validate user boundaries between sandboxes and production environments. After major updates, app deployments, or environment refreshes, permissions should be revalidated to ensure that configuration changes did not accidentally widen access or break execution flows.

  7. Secure Integrations and Automations

    Integration must be based on the service principals rather than human accounts to impose clean identity separation. Less-privileged permission sets should be granted to connectors, middleware, and API consumers to minimize exposure. Record-level security and record security filters should be checked to make sure that there is data isolation in multi-company or multi-brand situations.

  8. Monitor Permission Failures

    The telemetry, Event Viewer logs, or API status codes should be used to identify permission gaps. Repeated error messages such as “You do not have the following permissions...” indicate misaligned roles or missing permissions. The logging and analysis of these failures assists in the refinement of permission models without trial-and-error reassignments.

Business Central permissions are more than access controls; they are a governance model that protects financial accuracy, compliance, and operational integrity. With permission and licensing aligned, the least privilege roles, and the regular auditing of access, organizations may minimize the risk and maintain the productivity of teams.

If you want to design secure, scalable, and audit-ready security models in Business Central, Congruent Software can help you get there with confidence, talk to our experts today.