Your Staff Need a Till Login, Not the Owner's Account

You hire your first employee so you can spend less time behind the till. Then you realise the tablet you are about to hand over is signed in as you.

It takes payments. It also opens the management workspace where you change products, view financial information and administer the business.

The employee has not asked for any of that. They need to serve customers and deal with the ordinary mistakes that happen during a shift.

I would resolve that boundary before their first day working alone. A working till login is only the beginning of the handover. The useful question is what that person can reach and change after signing in.

The first employee changes the access question

An owner selling at farmers' markets described this exact concern in a discussion about POS access without backend access. Their employee would hold and use the tablet independently. The owner wanted to know: "Is there a way to allow access to the pos, but not the backend?"

That is one person's account of their setup, not a verified vulnerability or a verdict on the provider. It does identify a real handover problem: the screen staff are meant to use may not be the only screen available on the device.

A separate Shopify merchant discussion asked how associates could complete transactions without getting access to financials or product editing. The merchant was also trying to understand which account and subscription arrangement fitted that job.

Both questions are narrower than "Does the system have staff accounts?" They ask whether selling can be delegated without delegating the whole business.

Separate five things that often look like one login

Before opening the settings, write down the answers to five questions.

Device sign-in: Which account initially opens the application or browser session? Who can recover it if the device restarts or signs out?

Staff identity: How does the person starting a shift identify themselves? Can two people share the hardware while keeping their activity distinguishable?

Permitted actions: Which jobs can that identity perform? Selling, refunding, editing stock and opening sensitive reports should be considered separately.

Operating location: Which shop, market or stock location does the device use? A restricted role can still create the wrong stock movement if the location is incorrect.

Activity history: What record shows who did what? An order total alone may not explain who approved a refund or changed a product.

Current provider documentation illustrates why these distinctions matter. Shopify's PIN guidance separates initial account sign-in from staff PIN access, then treats permissions as a separate control. Its POS permissions documentation describes role-specific actions and approval settings, with POS roles dependent on POS Pro locations.

Square's permission-set guidance distinguishes team access from personal passcodes and individual attribution. Do not assume that sharing a team identity produces a person-by-person activity record.

Those are examples of different controls, not proof that every product handles them identically. A PIN can be useful without answering the separate question of whether an owner-level browser session remains accessible.

Write the job policy before choosing the role

Start with three roles and five everyday task groups. You can refine the policy later; first make the boundaries understandable.

The matrix below is an illustrative shop policy. It is not a tested EzyCarto permission catalogue or a promise that every provider supports each restriction.

Avoid choosing a role because its name sounds right. A role called manager may include functions that your shift manager does not need. Conversely, a tightly restricted cashier role may prevent a routine correction that the shop expects them to handle.

Define exceptions too. If a refund needs approval, who provides it when the manager is at lunch? If the answer is to share the owner's password, the policy needs another pass.

Check whether the software supports the required approval path, and whether an alternative procedure is acceptable where it does not. An unsupported control is a buying decision to resolve, not a setting to assume exists.

Run the handover on the device staff will actually use

Use a sandbox, demonstration environment or other non-production test setup with representative sample products and staff identities. Do not make real payments or expose private customer information to test a role.

First, sign in through the supported setup process. Switch to the cashier identity and complete an ordinary sample sale or equivalent non-payment exercise. Then attempt a task that should be denied, such as changing a product price or opening a restricted report.

Record the expected result and the observed result. Include the account, staff identity, device, location and relevant plan. "The button was not on the home screen" is weaker evidence than demonstrating that the restricted action is unavailable through the supported interface.

Repeat the exercise for the shift manager. Check an allowed correction and an action outside their authority. Finally, verify what the owner or authorised administrator must do to approve or configure the exceptional task.

For branch-specific stock and sales, use the separate multi-location assignment test. That guide checks where a movement belongs; this exercise checks who can initiate or change it.

Check what happens outside the tidy demonstration

The handover needs to survive ordinary interruptions.

Restart the device. Check which application, account and staff identity return. Determine whether the owner must intervene and what an employee can access before the normal selling screen appears.

Inspect the browser context. On a browser-based setup, check whether other open tabs or saved sessions expose management areas. A till shortcut or a full-screen presentation should not be treated as proof of permission enforcement.

Change staff mid-shift. Move from the first test identity to the second. Confirm that subsequent sample actions carry the right attribution. Check the supported lock or sign-out procedure rather than assuming inactivity clears everything.

Make the approver unavailable. Find out what the cashier can complete, what must wait and what escalation is permitted. Do not respond to every interruption by expanding the cashier's role.

Remove a test member of staff. Follow the provider's supported offboarding process. Check existing sessions on the intended devices and record any synchronisation requirement. Historical activity should remain interpretable after access is removed; verify how the product handles that too.

These are acceptance checks, not instructions to bypass security or an assurance that any particular product passes them. Ask the provider to explain a failed or ambiguous result before handing over live access.

Compare the plan against the job, not the account count

An extra user seat may not include the till-focused role you need. A staff feature may be tied to a particular location subscription. Device setup, sales attribution and management permissions can have different conditions.

Take your matrix into the evaluation and ask which current plan supports each required task. Keep the answer next to the tested result.

Do not use historical prices in a forum thread as today's quote. Do not upgrade solely because adding staff sounds like the next tier. Establish whether the arrangement actually prevents unnecessary access while allowing the employee to do the job.

Where EzyCarto fits

At EzyCarto, we connect checkout with the wider retail workspace. Our Back Office information documents supported business and module roles, with screens and actions depending on the assigned role and subscription plan. Smart Inventory describes function/location access and activity logs.

That public scope is not a claim that the exact cashier, approval and device-session behaviour in this example has been demonstrated for your shop. I would still ask to see your required tasks on the intended setup, including the action that must be denied.

Before handing over the till, run the three-role, five-task access check. Bring that policy into an EzyCarto Back Office evaluation, alongside your intended checkout device and location. Confirm which requirements the setup supports and resolve the rest before staff work alone.

The employee should leave that handover knowing how to do the job. The owner should leave knowing what has, and has not, been delegated.