Settings

Create an Employee User Account

Use New employee for every cashier, supervisor, accountant or API integration that needs its own traceable access.

Menu path: Manage -> Employees -> New
Verified from: Posnic demo and current POS source reviewed on 2026-09-08

Technical source evidence

Live local Posnic app reviewed 2026-09-09, frontend/modules/users.html New employee control, frontend/modals/user.html Add User drawer fields, frontend/static/script/js/modules/js/users.js addUserButton, clickNormalForm, clickApiForm, userForm, api/src/models/user.model.js identity, access, branch and status fields, api/src/controllers/users.controller.js inactive and missing-branch login checks

Current Posnic Add User drawer in Default User mode with identity and password fields — **Default employee identity**Default User mode creates a person who signs in with their own username and password. Never reuse another employee's account.

Current Posnic Add User drawer with branch selected and Cashier POS Operator role applied — **Branch and role assignment**Choose the operating branch, then select a reusable role. A named role fills its till and module permissions.

Current Posnic Add User permission matrix showing cashier module rights and Sales Session Filter — **Resolved module access**Review the role's resolved Read, Write and Delete matrix. Session Filter limits sales visibility to the user's login session.

Current Posnic Add User drawer showing lower permission rows Active InActive and Save controls — **Status and save**Set Active only when the account is ready to use. InActive prepares the record without allowing live login.

Before You Add the User

Decide the person's job first. A cashier, supervisor, inventory clerk, accountant and integration should not receive the same access just because setup is faster.

Know whether this is a Default User or an API User.
Choose the branch or branches the account may use.
Choose a role before you start ticking custom permission boxes.
Keep the first password temporary and change it using the shop password policy.
Do not create a live account in the public demo with real employee or customer data.

Create a Default User

Open Manage -> Employees.
Click New.
Keep Default User selected.
Upload a profile image only when the shop wants staff photos on record.
Enter First Name, optional Last Name, Username, Password, Retype Password and Email.
Choose at least one Branch. The current branch is preselected in the drawer.
Open Access Control.
Pick a Role such as Cashier / POS Operator, Shift Supervisor, Inventory Clerk, Accountant or Store Manager.
Review the populated Till / POS Actions and module matrix. A named role supplies and locks these values.
Choose Custom only for an approved exception, then tick the exact module permissions and POS actions this person may use.
Choose Active for a live account or InActive when preparing an account that should not yet log in.
Click Save, then open the row and confirm the role, branch and status.

Create an API User

API users are for integrations, scripts or external services. They receive an app name and generated API key instead of a normal staff password. The key is a credential: do not include it in screenshots, tickets, chat or documentation.

Open Manage -> Employees and click New.
Select Api User.
Enter the App Name.
Use generate key to create a key of at least 30 characters.
Assign the branch the integration is allowed to touch.
Grant only the read, write or delete scopes the integration needs.
Store the key immediately in the integration's secret configuration. Do not publish or email it.
Deactivate or revoke the API user when the integration is no longer used.

Role or Custom Matrix

Choosing a role fills and locks the module and POS-action matrix from the role. Choosing Custom leaves the boxes editable and saves the exact choices onto that user. Role selection does not make an ordinary employee an Admin account type.

Choice	Use it for	Operator result
Role	Most staff with normal job titles.	Changing the role later updates assigned users.
Custom	A one-off person with unusual access.	The user's own checkboxes decide access.
Admin type	Owner-trusted administrator only.	Broad access; do not use for daily cashier logins.
Normal type	Cashier or back-office worker.	Access comes from selected role or checked modules.
API type	Integration key user.	No normal password; app key controls API access.

Required Fields and Validation

Field	Rule	Why it matters
First Name	Required, letters only, 3 to 20 characters in the current form.	Identifies the person in staff records.
Username	Required and unique, up to 30 characters in the current form.	Used for login and audit trails.
Password	Required for Default User, no more than 20 characters in the current create form, and must match Retype Password.	Use the shop's strong-password policy even where the form accepts a weaker value.
Email	Required for Default User and unique.	Supports contact and duplicate checks.
Branch	At least one branch must be selected.	Without branch access the user cannot operate normally.
Access	At least one permission box is required for a normal custom account.	Prevents an unusable account.
API app name	Required and at least 3 characters in API mode.	Identifies which integration owns the key.
API key	API User key must be at least 30 characters.	Treat the generated value as a secret credential.

Understand Branch and Session Scope

Control	What it changes	Test before handover
Choose Branch	The outlets the employee can enter and operate.	Sign in and confirm only intended branches are available.
Role	Supplies reusable module and till-action permissions.	Compare the resolved checkboxes with the approved job role.
Sales Session Filter	Limits the user's sales view to transactions created during their own login session.	Create one controlled sale, sign out/in, and confirm the expected visibility.
Active / InActive	Inactive accounts are refused at login.	Keep pre-hire and suspended accounts inactive.
Register assignment	Determines which configured till the user can operate where register rules apply.	Open the employee detail after save and verify register access before a cash shift.

After Saving

Use Open it or the employee list row to review the new account.
Confirm the employee has only the branch and register access intended.
Sign out of the owner account and sign in as the new non-admin employee.
Confirm one allowed menu/action works and one disallowed area is absent or rejected.
Run one training sale only after payment, printer, barcode and register permissions are correct.
Test restricted Void sale and Refund / return behavior against the assigned role and manager approval setup.
Deactivate the account if setup was only a test. Never leave a shared test user active.

Creation Troubleshooting

Problem	Check	Resolution
Save says a field is required	Default and API modes use different required fields.	Default User needs identity, login, email and branch; API User needs app name, generated key, branch and access.
Save says at least one box	A Custom account has no selected access.	Select a role or grant only the approved custom permission boxes.
Username or email already exists	Another account owns the same identity.	Find and review the existing account. Do not create a spelling variation to bypass ownership review.
Employee cannot log in	Status may be InActive or branch access may be empty.	Review the employee record, activate only when appropriate, and assign the intended branch.
Permission boxes cannot be changed	A named role is selected, so its matrix is inherited.	Edit the reusable role for all holders or choose Custom for an approved one-person exception.
Employee sees unexpected sales	Session Filter is off or broader access is assigned.	Review the employee and role, then retest using that employee's own login.
API key was exposed	The key appeared in an unsafe screenshot, message or log.	Deactivate or replace the API credential immediately and update the integration securely.