Users, licenses, and permissions for a retail Business Central org

System admin · 12 min read

Most access problems in a retail Business Central org come from treating three different things as one. A license, a permission set, and a profile do different jobs, are changed in different places, and fail in different ways. Get the layers straight and the rest of this topic — POS staff accounts, seasonal hiring, least-privilege for store users — becomes a procedure instead of a recurring argument. License names and entitlements below follow Microsoft’s published licensing guidance; always confirm your own entitlements against the current Dynamics 365 Licensing Guide before buying or reassigning anything.

Three layers, three different jobs

• The license is the ceiling. Business Central online does not use the old Dynamics NAV license files. Instead, permissions are generated from entitlements: an Entitlements table defines license permissions per object, entitlement sets are tied to Microsoft Entra ID service plans, and when a user signs in, Business Central loads the entitlements that match that user’s service plan. No permission set can give a user more than their license entitles them to.
• Permission sets decide what a person can actually do. A permission set groups access rights per object — reading, inserting, modifying, deleting, and executing. Sets are assigned directly on the user card, in bulk, or in bundles through user groups. This is the layer admins adjust day to day.
• The profile only shapes the workspace. A profile (role) determines the user’s Role Center, navigation, and page experience. It controls what the user sees first — not what they are authorised to do. A store manager and a cashier can share a profile and hold completely different permissions, and the reverse is just as common.

When someone says “she has the wrong role, fix her access,” the fix is almost never in the profile. Work the layers in order: license first, permissions second, profile last.

The license layer: match the license to the retail role

Microsoft’s licensing guidance for Business Central names four paid license types for business users, plus a read-only route through Microsoft 365. Partner licensing guidance adds a device-based option that matters specifically in retail. None of these is a “retail license” — the mapping to store roles is an admin decision:

Two cautions belong with that table. First, do not buy from a price list in a blog post: prices and entitlements change, and the Licensing Guide is the document Microsoft points to for the detail. Second, the license and the permissions are set in different places — a user can hold the right license and still see nothing because no permission set has been assigned, which is the most common new-starter ticket in this whole area.

The permission layer: sets, user groups, and license defaults

There are three assignment routes, and a tidy org uses all three deliberately:

• Directly on the user card. On the Users page, select the user, choose Edit to open the User Card, and add lines on the User Permission Sets FastTab. Sets already assigned show in the Permission Sets FactBox. Setting the Company field on a line scopes that set to one company; leaving it blank applies the set to all companies — the single most useful control for multi-store orgs.
• In bulk. The Permission Set by User page, opened from the Users page, assigns sets to many users at once by ticking the user’s checkbox on each permission set line, with an All Users checkbox for sets everyone should hold. Set the Company name field there too, or the assignment lands everywhere.
• By license default. On the License Configuration page, an administrator picks a license, chooses Configure, and sets which permission sets and user groups new users on that license start with. Other permission sets are added automatically from the user groups assigned to the license. Two consequences matter: a new user created from a license — whether created automatically or through Update Users from Microsoft 365 — starts with those defaults, and changing the configuration afterwards affects only new users on that license. Existing users keep what they already have, so a “we fixed the defaults” change never retro-fixes the current team.

User groups are the bundle mechanism: group the sets a job needs, assign the group, and onboarding becomes assigning one group instead of six sets. In online deployments the account itself starts outside Business Central — the user is created in the Microsoft 365 admin center with a Business Central license assigned, then syncs into Business Central, where the admin assigns the user group or individual permission sets. Until that second step happens, the user exists but cannot do much. On-premises deployments differ: the license file (.bclicense or .flf) specifies how many user licenses exist, and the administrator creates, edits, and deletes users directly on the Users page.

Profiles are not permissions

This confusion deserves its own section because it generates real tickets. A profile decides the Role Center a user lands on and how their workspace is laid out. Permission sets decide authorisation. If a store user “can’t see” a page, the possibilities split cleanly: the page is not on their Role Center (profile or personalisation), or they lack a permission set covering the underlying object (permissions), or their license does not entitle that object at all (license). Changing the profile will never fix the second or third case, and handing out a bigger permission set will never fix the first. (Several common setup errors, including access shapes that only surface later, are covered in setup mistakes that break LS Retail.)

Least-privilege patterns for store users

• Guard SUPER. The SUPER permission set can read, use, update, and delete all data and all application objects within the scope of the license, and it cannot be modified. Business Central requires at least one user with SUPER in each database, and the first user created gets it automatically — which is exactly why SUPER spreads: it starts concentrated and leaks outward every time someone takes the shortcut. Keep it to named administrators, and review the list whenever someone changes jobs.
• Use SUPER (DATA) for the person who needs everything except change. This set covers all data within the license scope without application-object change rights, and is typically assigned to an accounting manager who needs to work with all data but does not need to change Business Central itself.
• Delegate with SECURITY, carefully. A user holding SECURITY can manage permission sets that are also assigned to their own account: create users and assign those sets, remove them, and modify permissions inside them. Because a delegate can never grant more than they hold, this is the safe way to let a head-office lead manage store staff access without giving them SUPER.
• Scope by company. A permission set assigned with a Company value applies only there; blank means everywhere. Store staff who should only work in their own store’s company get company-scoped sets. Head-office finance gets the blank — deliberately, and only them.
• Build groups per job, not per person. A cashier group, a store-manager group, a receiving group. When a person changes jobs, swap the group; when a job changes, edit the group once. Per-person set collections are how an org ends up with forty unique access shapes and no idea what any of them allow.

Onboarding and offboarding: the retail procedure

Seasonal hiring is where retail access control either works or collapses. Run the same procedure every time:

1. Create the account at the identity layer. Online: create the user in the Microsoft 365 admin center and assign the Business Central license that matches the job (full license for daily transacting staff, Team Member for light/approver roles). Then bring the user into Business Central with Update Users from Microsoft 365 on the Users page.
2. Assign the job’s user group (or its permission sets) on the user card, with the Company field set if the person works in one store’s company only. The license defaults give a starting point; the group gives the actual job access.
3. Set the profile so the first sign-in lands on the right Role Center. Then stop: do not add extra sets “just in case.” Missing access produces a ticket; excess access produces an audit finding.
4. Record the end date for seasonal staff at creation time. Access reviews fail on accounts nobody remembers creating; a named end date makes the offboarding list write itself.
5. Offboard by disabling first. A seasonal or departing user can be disabled temporarily inside Business Central, and permanently disabled from the Microsoft 365 admin center, with the change syncing into Business Central on the next Update Users from Microsoft 365 run. Disabling preserves the account while ending access immediately.
6. Delete only where deletion is possible. Users who have transactions in the system cannot be deleted — disable them and leave the record. Users with no transactions can be deleted, but clear their user personalisation first; personalisation is created automatically when users are updated from Microsoft 365 or sign in the first time.
7. Reclaim the license. Once the account is disabled in Microsoft 365, the license is free for the next hire. Do this in the same task as the disable, not at the next invoice.

What success looks like: a new seasonal hire signs in on day one, lands on the right Role Center, can do exactly their job in exactly their store’s company, and appears on an access list with a named end date. A departed hire’s account is disabled the same day, their license is back in the pool, and nobody had to delete anything to make it true.

Shared POS terminals and device licensing

Stores complicate the named-user model because a till is shared by everyone on shift. Partner licensing guidance describes the device license as the mechanism built for this: licensing attaches to the device rather than the person, multiple users share the device one at a time, and each user’s effective access is still governed by role-based permissions. Two admin rules follow. First, a device license is not a reason to give the shared sign-in broad permissions — the permission layer still decides what can be done, so the till’s access should be the till’s job and nothing more. Second, auditability lives in the permission layer, not the license: if everyone on shift works under one undifferentiated account, no license type will reconstruct who did what, so keep individual accountability in how accounts and permission sets are assigned even on shared hardware. Verify the current device licensing terms in the Dynamics 365 Licensing Guide before restructuring around them.

Troubleshooting by layer: a decision framework

When access is wrong, test the layers in order — each layer has a distinct symptom:

1. License: the user cannot sign in at all, or an entire area of the product is out of reach for every user on the same license. Check the license assignment in Microsoft 365 and whether the object is inside that license’s entitlements.
2. Permissions: the user signs in and works, but a specific action or object is denied. Check the Permission Sets FactBox on the user card and the User Permission Sets lines, including whether a Company value is scoping the set away from where the user is working.
3. Profile: the user can do the work when they navigate to it directly, but their home workspace does not surface it. That is the Role Center, not authorisation — fix the profile or personalisation, not the permission sets.

Working top-down prevents the classic failure mode: escalating permissions (the layer that feels most powerful) for a problem that lives in the profile, and leaving the org less secure than before the ticket arrived.

FAQ

A new starter has a license but sees almost nothing. Why?
The license only sets the ceiling. Until a user group or permission sets are assigned on the user card, the user exists but cannot do much. Assign the job’s group and check again before touching anything else.

We changed the license defaults but existing staff are unchanged. Is that a bug?
No. Customised License Configuration affects only new users assigned that license; permissions for existing users are not changed. Update existing users deliberately, per user or in bulk.

Can a leaver’s account just be deleted?
Only if they have no transactions in the system, and after clearing their user personalisation. Anyone with transactions must be disabled instead — in Microsoft 365, syncing through, or temporarily inside Business Central.

Does a Team Member license fit a cashier?
Only if the person’s real work matches Team Member’s light pattern — reading data with limited writes such as approvals and timesheet-style updates, per its default permission sets. A cashier transacting all day on a shared terminal is the device-licensing conversation, not a Team Member conversation. Confirm entitlements in the Licensing Guide before deciding.