Staff accounts, roles and access

Inviting staff, and controlling exactly what each person can see and do.

Access has two independent layers, and understanding the split is what makes this predictable.

LayerControlsSet in
PagesWhich parts of the app someone can open at allSettings > Users > Access > Pages
ActionsWhat they may do there — view, create, edit, deleteSettings > Users > Access > Actions

Someone needs both. Granting the Inventory page without edit rights gives a person who can look and not touch; granting edit without the page gives them nothing they can reach. The editor shows both together for exactly this reason.

Roles are the starting point

A role — Cashier, Pharmacist, Accountant — sets sensible defaults for both layers. Anything you have not customised follows the role, so you only touch the people who need something different. A dot on the tab shows when a person has been customised away from their role.

Where several pages share one switch

The Actions tab groups rights the way the system enforces them, and some rows govern several pages at once — Products, Categories, Departments, Promotions and Variants are one right, not five. Each row names every page it covers, so you can see what a change will affect before you make it. "Delete on Products but not Categories" is not something the system can express.

View comes first

Granting create, edit or delete automatically grants view, and removing view removes the rest. Being able to act on a page you cannot open is not a real state, so the editor will not let you build one.

Owners and admins

An Owner or Admin always has everything. This is deliberate: someone must be able to undo a lockout, so the switches that restrict staff do not apply to the account that owns the business.

Changes take effect on the person's next request, or when they next focus their tab — they do not need to sign out and back in.