New store staff onboarding for Business Central and LS Central: a systems checklist

Store operations · 7 min read

Generic onboarding checklists cover the tour, the uniform, and the buddy. They do not cover the part that actually stops a new hire from working — or, done carelessly, gives them far more access than the job needs. In a Business Central and LS Central store, one person needs two separate kinds of access, created in a specific order, plus a training sequence that follows the risk of the tasks. This is the systems checklist.

Two systems, two kinds of access

Keep these layers separate in your head, because they are separate in the software:

The LS Permission Group on the staff card is explicitly a different thing from Business Central permission sets. A cashier can need a staff record and no BC user at all; a store manager usually needs both. Deciding which layers each role needs is the first onboarding decision — make it by role, once, not per hire.

Before day one: create the accounts in order

1. Create the Microsoft 365 account and assign the license first. For Business Central online, user accounts must be created in the Microsoft 365 admin center before they can exist in Business Central — there is no creating the BC user first and bolting the account on later.
2. Import the user into Business Central. Run Update Users from Microsoft 365 on the Users page rather than waiting for the account to appear at first sign-in; the import gives the administrator control over starting permissions, groups, and profile before the person ever logs on. Note that running it requires the SUPER permission set — this is an admin task, not a store task.
3. Create the LS staff card. The staff card carries the fields the POS needs: the staff ID the person logs on with, name, store number, LS Permission Group, password, and — only when the person genuinely uses profiles different from the store or terminal defaults — their own POS profiles. Staff who work in more than one store get Store Links rather than a second staff record.
4. Test both sign-ins before the first shift. The admin, not the new hire, discovers a broken login: sign in to the POS with the new staff ID and, if the role includes it, to Business Central with the new user.
5. Prepare the non-system basics in parallel: standard retail pre-boarding practice — accounts, equipment, a named buddy, and the first week's training sessions booked — applies here unchanged; the systems steps above slot into the same pre-boarding window.

Assign permissions by role, not by person

Three rules keep this from becoming a tangle:

1. Start from the license defaults, then trim. A new BC user's starting permission sets come from the license configuration and the groups assigned to that license. Review what the role actually received instead of assuming the default fits a store job.
2. Scope by company where the role is store-scoped. On the User Card's User Permission Sets FastTab, a set with the Company field filled in applies only to that company; blank means all companies. Multi-store staff are the exception to grant deliberately, not the default. For batches of hires, the Permission Set by User page assigns sets to multiple users at once, and user or security groups let you change one set for many users in a single action — use groups so the tenth hire gets exactly what the first one got.
3. Set POS limits in the staff permission group. LS staff permission groups carry the till-level differences between roles such as cashier, manager, and key holder — a documented example is a cashier group capped at a 5% maximum discount that cannot open the cash drawer without a sale. After setting the group, open the staff member's permissions from the Staff List and check them individually; LS Central supports per-person exceptions on top of the group, which is exactly why the check matters — exceptions accumulate silently.

Decision framework for any permission request during onboarding: does the task require it this week, is it in the role's group already, and who approves exceptions? If the answer to the first is no, the request waits — adding access is easy later; auditing access nobody remembers granting is not.

POS sign-in basics to cover first

• Staff log on to the POS with their own unique ID, or ID plus password. Shared logins destroy accountability for every discount, void, and drawer opening that follows — day one is when the "always your own ID" rule is set.
• Show what their permission group allows and blocks, live: attempt the tasks they can do, and let them see a manager-level action refuse and ask for authorization. Knowing the boundary exists prevents both queue-side embarrassment and workarounds.
• Cover what happens when the connection drops before it happens on a Saturday — offline behaviour is covered in POS offline mode.

The training sequence

Order training by task risk, not by menu order. LS Retail's Academy exists because structured training is what builds competence on this system — store onboarding should borrow that order:

1. Sign-in, sign-out, and lock: their ID, their responsibility.
2. The plain sale: scan, tender, receipt, change. Nothing else until this is boring.
3. Price and item lookups: what to do when a barcode will not scan or a price looks wrong — escalate, never improvise a price.
4. Returns and exchanges, including which steps need manager authorization under their permission group.
5. End-of-day tasks their role touches, following the store's normal close routine (see the end-of-day routine).
6. Back-office tasks last — receiving, counts, Business Central pages — and only for roles whose permissions include them.

Shadowing and the first supervised shifts

Assign the buddy before day one, as standard pre-boarding practice prescribes, and make the shadowing directional: first the new hire watches a full shift with the trainer narrating the why behind each step, then roles reverse — the hire runs the till while the trainer watches and corrects in the moment. Keep the hire off solo shifts until they have completed at least one supervised close if their role includes end-of-day work, because the close is where small misunderstandings become reconciliation problems.

First-week checks

1. Review their transactions: scan the week's sales under their staff ID for unusual discounts, voids, or no-sale drawer openings — and confirm the pattern matches their permission group.
2. Test the boundaries again: have them attempt one action above their role in a quiet moment. It should refuse cleanly. If it succeeds, the permission assignment — not the hire — is the problem.
3. Ask what they could not do that the job required. Missing access found in week one is a five-minute fix; found in month two, it has usually already produced a shared-login workaround.
4. Confirm the buddy handoff is done and the store lead signs off the checklist. Onboarding that is not signed off tends to be onboarding that is not finished.

When someone leaves: remove access the same day

Onboarding's mirror image is the step generic checklists never mention:

1. Block the staff card. Selecting Blocked on the LS staff card disables that person's POS log-in — use it for leavers and for seasonal staff between seasons.
2. Disable the Business Central user. On the User Card, set Status to Disabled: the user can no longer sign in and active sessions are stopped, while references to their past work are kept. A user who has signed in to BC online cannot be deleted, so disabling — plus removing the license in the Microsoft 365 admin center where appropriate — is the removal mechanism, not deletion.
3. Rotate anything shared the person knew: safe combinations, alarm codes, shared mailbox passwords. Their individual accounts are handled by steps one and two; shared secrets are the gap those steps do not close.

What success looks like

• The new hire signs in to the POS (and BC, if their role needs it) on their first shift, first try, with their own ID.
• Their permission group blocks at least one manager-level action when tested — and allows everything their first week's tasks require.
• Every access they hold traces to their role's template, with any exception named and approved in writing.
• The leaver's checklist exists and is used: a departed staff member's POS login is blocked and their BC user disabled on their last day, verifiable in both systems.