Permission sets in Business Central: store staff access without the keys to the kingdom

Configuration · 9 min read

The fastest way to give away the business in Business Central is also the most common: a new store employee needs to "just do their job," nobody has time to design access properly, and the account gets SUPER. Weeks later the same account can open financial data, change setup, and assign permissions — not because anyone decided that, but because nobody decided anything. Permission sets exist to make that decision once, properly, and then reuse it for every person in the same role.

This guide builds store-staff access the disciplined way: start from what the role actually does, scope the result to the right company, and prove — on the page Microsoft provides for exactly this purpose — that the finished access is what was intended.

Permissions, licences, and profiles are three different things

Three mechanisms are constantly confused, and the confusion causes most access problems. First, the licence: in combination with the user's licence, the Business Central security system controls access to objects in each database or environment, and the first level of permissions is the overall permission granted by the licence itself — the entitlement, which includes default permission sets. Second, the detailed permissions assigned inside Business Central, organised as permission sets: a permission set is a collection of permissions for specific database objects, and all users must be assigned one or more permission sets before they can access Business Central at all. Third, profiles: profiles define which features are available in the user interface and how users interact with them, assigned by job role or department. A profile shapes what a person sees; it does not grant or deny access to data. Giving a store employee a tidy Role Centre is good practice — it is not a security control, and treating it as one leaves the underlying access wide open.

SUPER sits at the extreme of the second level. If a user's access should not be restricted beyond what the licence already defines, the SUPER permission set grants access to all objects specified in the licence. Note the licence interaction: a user with the Essential licence and SUPER has access to more functionality than a user with the Team Member licence and SUPER, because SUPER removes restriction only within the licence's own scope. For store staff, that is still far too much scope — SUPER is an administrator's set, and every non-administrator holding it cancels out the careful sets assigned alongside it.

A least-privilege framework for store roles

Decide access by role before touching a single user account. The framework below uses only documented mechanics; the role names are the store's own, the levers are Business Central's.

Two calculation rules from the documentation should govern every design decision. If a permission appears in both an included and an excluded permission set, the permission is excluded — Business Central calculates the full included list, then the excluded list, then removes the excluded permissions from the included ones. Exclusion is therefore the reliable trimming tool. And indirect permission is the professional's middle setting: a user with Indirect permission on a table can modify it only by running an object that itself has permission, such as a posting codeunit, and cannot modify the table by other methods. Posting-style tasks for store roles should be built on indirect access wherever the design allows it, so the action is possible through the proper process and impossible around it.

Procedure: build, scope, and assign a store-staff set

1. Start from a copy, not a blank page. On the Permission Sets page, select the existing set closest to the role and use the Copy Permission Set action, naming the new set for the role. Choose the copy operation deliberately: Copy by reference keeps the original and its added sets listed, Flat permission copy flattens everything into one list, and Clone makes an exact copy. A useful side-effect of building from system sets: when Microsoft changes permissions in a system set, a user-defined set based on it is updated automatically — one less drift source to audit.
2. Trim with exclusions. Open the new set with the Permissions action. On the Permission Set page, use Type to include or exclude permissions per object, setting the Read, Insert, Modify, and Delete levels and the Execute level for codeunits and reports. Exclude financial setup, payment, and user-administration objects the role never touches. Remember the one caution Microsoft flags explicitly: granting Insert or Modify on the User Group Member table (9001) or the User Group Permission Set table (9003) can let users assign themselves to other user groups and gain unintended permissions — store-staff sets should never carry either.
3. Add record-level limits where the role needs them. For Table Data objects, use the Security Filter field to filter the data the user can access — the documented example limits a user to records about a particular customer. In a store context this is the lever for roles that should see a slice of a table rather than the whole table, and it is configured per table inside the set.
4. Assign by group where possible, by user where necessary. Security groups exist to make this manageable: organise users in security groups and assign or change one permission set for many users in one action, with every member of the group receiving the group's sets. For direct assignment there are two documented routes: on the User Card, add the set on the User Permission Sets FastTab; or on the Permission Set by User page, select the user-name checkbox on the line for the set — or All Users to assign it to everyone, which store-staff sets should essentially never use.
5. Scope the assignment to the company. On either assignment route, fill the Company field with the store's company so the set applies only there; leave Company blank only when access to all companies is genuinely intended. A role that exists in several companies but not all of them is handled by adding the set separately for each company.
6. Set the surrounding user controls. Access is more than object permissions. In User Setup, administrators can define the periods during which specified users may post, specify whether the system logs how long users are signed in, and assign responsibility centres to users. Posting windows belong in the store-staff design from day one, not after the first out-of-period posting.

Recording a set from real tasks

Hand-picking objects is error-prone for roles with long task lists, and Business Central offers a second construction method: recording. On the Permissions page, choose Record Permissions, then Start. A recording process captures actions in the user interface while the tasks the role should perform are carried out in the normal pages. Return to the Permissions page, choose Stop, then Yes to add the recorded permissions to the set, and for each recorded object specify whether users may insert, modify, or delete records in the recorded tables. Recording produces a set shaped by real work instead of by guesses about which tables a task touches. Its limit is symmetric: it captures only what was performed during the recording, so record the full task list for the role — including the occasional month-end task — or the missing permission will announce itself at the worst moment. Sets also travel: permission sets can be exported and imported as XML between tenants with the Export Permission Sets and Import Permission Sets actions, which is how a proven store-staff set should be replicated to a new environment instead of being rebuilt from memory. Stale entries can be cleaned with the Remove Obsolete Permissions action on the Permission Sets page.

What success looks like

Do not declare the work done when the set is assigned — declare it when it is verified. Verification uses the Effective Permissions page, which shows a user's effective permissions together with the source of each permission, such as a security group or inheritance, and the security filters that apply. Viewing another user's effective permissions requires the SECURITY or SUPER permission, and only permission sets of type User-Defined can be edited from that page. The check itself is a spec verification, done set by set: open the test or real staff account, open Effective Permissions, and confirm three things. First, every permission present traces to an intended set in the By Permission Set part — no unexplained grants. Second, the dangerous objects trimmed in the procedure are genuinely absent, remembering that entitlement rows can overrule other sets when the entitlement carries the higher ranking, in which case the lower value shows in brackets as not effective. Third, the company scoping is what was intended: the set appears for the store's company and not as a blank, all-companies assignment. When a permission set is edited later, remember the change applies to every user holding that set — which is the point of role-based design, and also why changes deserve the same Effective Permissions re-check.

The finished state for a store is simple to state: no store-staff account holds SUPER, every account's access traces to a named role set scoped to its company, posting periods are set in User Setup, and a new starter in the same role is provisioned by adding them to the security group — one action, no permission archaeology. Anything less is not a permission design; it is a hope.

Disclaimer: this article is general configuration guidance based on Microsoft's published Business Central documentation, not security or professional advice for a specific environment. Validate new permission sets with a test user in a sandbox or copy company before assigning them to live store accounts.