# Fixing "You do not have the following permissions on TableData (table): (permission)" in Business Central AL > Source: https://netray.co/erp-help/dynamics-business-central-al-tabledata-permission-error > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System dynamics ## Erp Microsoft Dynamics 365 Business Central ## Module AL extensions / Permission sets ## Query You do not have the following permissions on TableData: Insert Business Central ## Alternate Queries - Business Central AL extension permission error - TableData permission missing Insert Modify Delete Business Central - You are not allowed to access table Business Central ## Applies To Dynamics 365 Business Central, cloud (SaaS) and on-premises, current and prior AL extension model versions. ## Steps ### Grant the missing table permission **Items:** - Note the exact table name and permission letter (Insert, Modify, Delete, Read/View, Execute) reported in the error. - Open the Permission Sets page and check which sets are assigned to the affected user, either directly or through a User Group. - If 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. - Republish the extension so the updated permission set is deployed, then reassign or re-verify the permission set on the affected user or user group. - If 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. - Use 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. - Have the affected user sign out and back in, or start a new session, since permission changes are not always picked up mid-session. - Test 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. ## Sections ### Why this happens even for tables you own **Body:** 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 **Body:** 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. **Code:** - permissionset 50100 "My Ext - User" - { - Assignable = true; - Permissions = tabledata "My Table" = RIMD; - } ### Diagnosing which set is actually missing the grant **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### What do the R, I, M, D, X letters mean in an AL permission set? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms you do not have the following permissions on tabledata, business central al permission error, business central table permission insert error, al permission set tabledata example, business central effective permissions page, business central extension permission missing, bc365 al RIMD permission letters, business central user group permission set, al permissionset object example --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json