Business Central permission errors

Business Central's permission model is table-and-object-level: a permission set grants specific access (Read, Insert, Modify, Delete, Execute) to specific tables, pages, reports, and codeunits, and a user needs the union of everything their assigned permission sets grant. When that union is missing one object, the error is usually specific about which object — but decoding what that object actually means in business terms is the hard part.

"You do not have the following permissions on TableData [Table Name]: Insert"

Symptom. A user tries to create or post a document and the action fails with this exact permission message, naming a table and an operation (Insert, Modify, Delete, or Execute).

Cause. No assigned permission set grants the required operation on that specific table. This is common after a new feature starts writing to a table nobody thought to grant (a new posting routine, an extension's own tables) or after a permission set was trimmed to reduce access without testing every workflow that depends on it.

Fix. Identify which permission set should logically cover this table (or add a new one), grant the missing operation, and reassign it to the user or their user group. The Permission Set page's "Where Used" style lookups and the standard permission sets' documentation help identify the right owner rather than guessing.

Prevention. Test every permission set change against a representative user's full workflow — end to end, not just the screen that was being modified — before rolling it to production. A trimmed permission set that works for 95% of a role's daily tasks still generates tickets for the other 5%.

"You do not have the following permissions on Codeunit [Name]: Execute"

Symptom. An action or a background job fails naming a codeunit rather than a table.

Cause. Codeunits carry their own executable permission separate from the tables they touch — a permission set can grant every table operation an action needs and still fail if the codeunit that runs the action itself isn't executable for that user.

Fix. Add Execute permission on the named codeunit to the relevant permission set. AL extensions typically ship a permission set covering their own codeunits; if the error names a codeunit from an installed extension, check whether that extension's permission set was actually assigned, not just installed.

Prevention. When installing a new AL extension, assign its shipped permission set to the relevant user groups as a deliberate step in the rollout checklist — installing an extension does not automatically grant anyone permission to use it.

"The permissions specified for user group [X] conflict with company [Y]"

Symptom. A permission set assignment fails or behaves inconsistently when a user group is scoped to specific companies in a multi-company tenant.

Cause. Business Central lets user group permission assignments be company-specific; a user group meant to apply everywhere but only assigned in one company silently doesn't apply in others.

Fix. Check the User Group and User Group Members pages for company scoping and extend the assignment to every company the user actually needs.

Prevention. In a multi-company tenant, decide explicitly at design time whether permission sets are meant to be identical across companies or genuinely different, and document which — assuming "it'll just apply everywhere" is the most common cause of this class of ticket.

Job queue entries failing with a permission error

Symptom. A scheduled job queue entry that used to run fine starts failing with a permission error, with no user actively doing anything at the time.

Cause. Job queue entries run under a specific stored user context (see job queue), and that user's permissions can change — a permission set unassigned, an account disabled — independently of anyone touching the job queue configuration itself.

Fix. Check the permission set assignments for the job queue entry's configured user, not the permissions of whoever is investigating the ticket.

Prevention. Use a dedicated service-style user (not a named employee's account) for job queue entries and integrations, so a personnel change or an individual's permission review never silently breaks a scheduled job.

Where to go next

Permission set design as a whole is covered in permissions and security in Business Central. For the errors that show up when posting groups rather than permissions are missing, see posting setup errors.