POS sign-on and cashier permissions: who can do what at the LS Central till

Store operations · 8 min read

"The till let her do it" is not a permissions strategy. In LS Central, signing on to the POS and being allowed to do something at the POS are two separate mechanisms, set up in different places, by different means. When a refund goes out that shouldn't have, or a discount sails past the limit everyone assumed existed, the cause is almost always that one of the layers below was never actually configured — or was configured and never verified at the till.

Signing on is not permission

Sign-on is handled by the Staff card. It carries the User ID, name, Store No., password, and Store Links for staff who work in more than one store, along with optional POS profiles where a person needs something different from the store or terminal defaults. At logon, the POS asks the Transaction Server for the staff member's status; the staff record is copied to the POS database and processed locally from there. If the POS can't reach the Transaction Server, it falls back to the staff information already in its local database to decide whether logon is allowed.

One field on that card matters more than the rest: Blocked. The POS checks it first — a blocked staff member cannot log on, full stop. Blocking is the correct way to end a leaver's or a seasonal worker's till access; it disables POS log-in without deleting the record. If your store's leaver process doesn't include blocking the staff card on the last day, your permissions setup has a hole no other setting can close.

None of that, however, decides what a signed-on person can do. That's the layers below.

The four control layers, compared

To make the back-office layer concrete: in LS Express, LS Retail's other Business Central POS product, access is expressed entirely as Business Central permission sets — a full-access set for POS administrators, a base set for cashiers who operate the POS but don't configure it, and a read-only set for back-office staff who only need to view data. LS Central keeps that back-office layer and adds the till-side layers above. Granting someone a generous permission set in Business Central does not, by itself, loosen what the till will let them do — and tightening the till layers does nothing to their back-office access. Audit both.

Which functions to gate first

Not every command needs a manager. Gate too much and managers spend the day typing credentials at the till while the queue builds; gate too little and the controls are decoration. Work through the decision this way:

• Does it move money out of the drawer or reverse a completed sale? Gate it. Voiding transactions and issuing refunds are the textbook cases: LS Retail's own guidance uses a void-transaction-line button restricted to a managers-only group as its example for Staff Group Access.
• Does it change the price the customer pays, beyond a small allowance? Cap it in the permission group rather than gating it outright. A documented example setup gives the cashier group a 5% maximum discount and no ability to open the drawer without a sale — small discounts flow, large ones hit a wall.
• Does it change how the till itself behaves? Gate it. Training mode is the example LS Retail gives for the Manager Key: set the field to TRUE on the TRAINING command and only users with manager credentials can put the POS into training mode — a state you never want entered accidentally or casually.
• Does the screen itself show something sensitive? Gate the menu, not the button. The Manager Key can be set on a whole POS menu, restricting the menu and all its functions to managers in one move.
• Is it ordinary selling? Leave it open. Scanning, tendering, and suspending a sale are the job; friction there buys no control.

The manager override is a designed path, not a workaround

When a cashier hits a gated function, the flow isn't "go find a different till." LS Central's command list includes MGRKEY, the Manager Login Key command: it lets a store manager log in at the terminal without the cashier logging out, precisely for the cases where an action requires a manager login. The manager authorizes the one action; the cashier's session continues. If your staff's actual practice is sharing a manager's sign-on "because it's faster," the gating you configured is being bypassed socially, not technically — and the fix is making MGRKEY easy to reach on the layout, not loosening the gates.

Set it up in this order

1. Clean up the Staff cards first. One card per person, correct Store No., Store Links for anyone who genuinely works multiple stores, and Blocked set for everyone who has left. Shared sign-ons make every other layer meaningless.
2. Define the permission groups. Typically cashier, key holder, and manager — the group setup is meant to be modified per location, so set the limits (maximum discount, drawer-open-without-sale) per group rather than accepting a single generic group for everyone.
3. Assign each Staff card its group in the LS Permission Group field, and confirm nobody carries a broader group "temporarily" from a past cover shift.
4. Set Manager Key to TRUE on the commands and menus from your gating pass — training mode and any menu showing sensitive information are the usual first entries.
5. Set Staff Group Access on the money-out buttons — voids and refunds first — naming the managers-only group.
6. Review the back-office side separately. Check Business Central permission sets for the same people, remembering they govern back-office pages, not till behaviour.

Verify at the till

Configuration screens prove intent. Only the till proves behaviour. Run this audit with a cashier sign-on, not a manager's:

1. Sign on as a cashier and attempt a void of a transaction line. Success looks like: the action is refused or demands manager credentials — it does not complete.
2. Attempt a refund. Same expectation: blocked or escalated, never silent.
3. Apply a discount above the cashier group's maximum. The till should stop it at the group limit, not merely warn.
4. Try to open the drawer with no sale in progress, if the group forbids it. The drawer stays shut.
5. Try to enter training mode. With Manager Key set on the command, a cashier sign-on can't.
6. Now have a manager use MGRKEY at the same terminal and repeat step 1. The void should proceed under the manager's login while the cashier's session stays in place — this proves the escalation path works, not just the wall.
7. Sign on with a blocked staff card (use a test card). Logon must be refused.

What success looks like

Every gated action either completes under the right credentials or stops with a manager prompt; nothing on the list silently succeeds under a cashier sign-on; the manager override works without ending the cashier's session; and a blocked card cannot sign on at all. If any step behaves differently, the layer responsible is the one from the table above — fix it there, re-run just that step, and only then call the audit done. Permissions that were set once and never tested at the till should be treated as unconfigured, because in every way that matters, they are.

FAQ

Is the LS Permission Group the same as a Business Central permission set?
No. The Staff card documentation states the LS Permission Group is different from the NAV/BC permission sets. The group governs till behaviour for the signed-on staff member; permission sets govern back-office access in Business Central.

A seasonal worker is coming back next month. Delete or block the card?
Block it. Blocking disables POS log-in while keeping the record intact, so re-enabling is a single change when they return — and while blocked, the POS refuses the logon outright.

The POS couldn't reach the server this morning. Were permissions still enforced?
Sign-on, at least, falls back to the staff information in the POS's local database when the Transaction Server doesn't answer, including the blocked check. That makes keeping local data current — and blocking leavers promptly — matter even more, because a stale local copy is what an offline till will trust.