Error fixMicrosoft Dynamics 365 Business CentralAL extensions / Permission sets

Fixing "You do not have the following permissions on TableData (table): (permission)" in Business Central AL

Error
You do not have the following permissions on TableData: Insert Business Central

Also searched as

  • Business Central AL extension permission error
  • TableData permission missing Insert Modify Delete Business Central
  • You are not allowed to access table Business Central

Short answer

This runtime error means the current user's assigned permission sets do not grant the required Insert, Modify, Delete, Read, or Execute right on that specific table. It is most common right after installing or updating a custom AL extension, because Business Central checks object-level permissions even for tables an extension owns.

Applies to: Dynamics 365 Business Central, cloud (SaaS) and on-premises, current and prior AL extension model versions.

Grant the missing table permission

  1. 1Note the exact table name and permission letter (Insert, Modify, Delete, Read/View, Execute) reported in the error.
  2. 2Open the Permission Sets page and check which sets are assigned to the affected user, either directly or through a User Group.
  3. 3If the table belongs to a custom AL extension, open or create a PermissionSet object in that extension's source, and add a TableData permission line for the table with the required access letters.
  4. 4Republish the extension so the updated permission set is deployed, then reassign or re-verify the permission set on the affected user or user group.
  5. 5If the table is a standard Business Central table, edit an existing custom permission set (do not modify built-in sets) to add the TableData line instead.
  6. 6Use the Effective Permissions page for the user to confirm the final combined permission after all assigned sets, since another set can still be denying or simply not granting the right.
  7. 7Have the affected user sign out and back in, or start a new session, since permission changes are not always picked up mid-session.
  8. 8Test with a non-administrator account before go-live; SUPER or admin accounts will not reproduce this error even if a real user's permission set is missing the grant.

Why this happens even for tables you own

Business Central enforces object-level permission checks on every table access, regardless of whether the table is a standard system table or one defined inside your own AL extension. Publishing an extension does not automatically grant any user rights to its objects; a permission set has to explicitly include TableData entries for the extension's tables, and that set has to be assigned to the user.

This catches teams most often immediately after deploying a new extension: development and testing happened under an administrator account that implicitly has full rights, and the gap only appears once a normal business user tries the same action.

Defining a permission set in AL

A permission set object lists TableData permissions using the letters R (Read), I (Insert), M (Modify), D (Delete), and X (Execute) for codeunits. A minimal example for a custom table looks like this.

permissionset 50100 "My Ext - User"
{
    Assignable = true;
    Permissions = tabledata "My Table" = RIMD;
}

Diagnosing which set is actually missing the grant

The Effective Permissions page (search for it in Business Central) shows the combined result of every permission set assigned to a user, which is the fastest way to confirm whether the fix actually closed the gap rather than guessing from the Permission Sets list alone.

In multi-extension environments, remember that permission sets from different extensions are additive: a user can have full rights from one set and still be missing a single letter from another table's permission line, which produces this exact error only on that one action.

Common pitfalls

  • !Testing only with SUPER or administrator accounts, which never surface missing permissions during development.
  • !Editing a built-in Business Central permission set instead of creating or extending a custom one.
  • !Granting a permission set but forgetting to assign it to the specific user or their user group.
  • !Renumbering or renaming AL objects, which can silently break existing TableData permission references tied to the old object.
  • !Assuming a permission change takes effect immediately without a fresh sign-in or session.

How an ERP-grounded AI assistant handles this

ERPray for Business Central can compare the runtime error's table and permission letter directly against the AL source of a tenant's installed permission sets, point to the exact PermissionSet object (or the absence of one) causing the gap, and draft the missing TableData line, turning a manual hunt across the Permission Sets and Effective Permissions pages into a direct answer.

Frequently asked questions

What do the R, I, M, D, X letters mean in an AL permission set?

R is Read, I is Insert, M is Modify, D is Delete, and X is Execute (used for codeunits and reports rather than tables). A TableData permission line can combine any subset of these letters for a given table.

Why does my admin account not see this error but a normal user does?

SUPER and full administrator accounts have implicit rights to every object, so permission gaps in a custom or edited permission set will only surface for accounts that rely on the explicitly assigned permission sets, which is why testing with a restricted test user matters.

Does publishing an AL extension automatically grant permissions to users?

No. Publishing deploys the objects and any permission sets defined in the extension, but a permission set still has to be assigned to a user or user group before that user gains the rights it defines.

Where do I check what permissions a user actually has after all assignments?

Use the Effective Permissions page for that user. It shows the combined outcome of every assigned permission set, which is more reliable than reading each set individually when several extensions are involved.

Related

Error fix

Fixing "Cannot create a record in (table). The record already exists" in D365 F&SCM data entity imports

This is the standard kernel duplicate-key exception, thrown when the Data Management Framework tries to insert a staging row into a target table whose unique or alternate key already matches an existing record. It almost always means the entity's insert-vs-update logic did not recognize the target row as an update, not that you have a true accidental duplicate in your source file.

Error fix

Fixing "The CIL object was not found" in Dynamics AX 2012

This error appears when the AOS tries to execute compiled CIL for a class or method that has not actually been regenerated since a code change was imported or edited, so the .NET runtime has nothing matching to run. The fix is a full compile followed by a full CIL generation and an AOS restart, not just a partial or incremental rebuild.

How-to

Handling OData 429 Too Many Requests throttling in D365 Finance and Operations

D365 F&SCM protects shared AOS capacity by throttling OData and custom service calls, returning HTTP 429 with a Retry-After header once a client sends too many requests too quickly. The durable fix is to honor Retry-After with backoff and redesign high-volume or frequent-polling integrations to use batching, business events, or Data management instead of tight request loops.

Error fix

Fixing "There are currently no batch servers available for processing" in D365 F&SCM

This message means the batch framework cannot find any AOS instance flagged as a batch server and available for the batch group the job is assigned to. The fix is almost always in server configuration (System administration > Servers) or batch group assignment, not in the batch job itself.

How-to

Setting up Electronic Reporting (ER) formats in D365 Finance and Operations

Electronic Reporting (ER, also called GER - Global Electronic Reporting) is the D365 F&SCM framework used to generate country-specific tax reports, e-invoices, and payment files without X++ code. You build it in three layers: a data model, a model mapping to source tables, and a format that renders the mapped data. Work is done under Organization administration > Electronic reporting.

How-to

Calling and extending the Business Central API v2.0

The Business Central API v2.0 is a REST/OData endpoint at api.businesscentral.dynamics.com/v2.0/{tenant}/{environment}/api/v2.0, authenticated with Azure AD OAuth 2.0. It exposes standard entities like customers and items, and lets you publish your own with an AL API page.

AI for ERP

AI for Dynamics 365 Business Central, on-premises or SaaS, beyond Copilot

AI for Business Central beyond Copilot: grounded question answering over BC's data via OData and APIs, for on-premises and SaaS tenants alike.

Stuck on Microsoft Dynamics 365 Business Central?

Talk to engineers who work inside Microsoft Dynamics 365 Business Central every week, and who build private AI that answers these questions from your own ERP data.