Operations · 7 min read
How to set up roles and permissions so staff only see their job
When a business adds POS, stock, purchases, baaki, and HR, the owner’s temptation is to give every login the same access “for now.” That “for now” lasts until a cashier sees cost price, a trainee voids a settled sale, or someone edits roles they should never touch.
Workcel’s answer is company roles: named jobs with a checked list of permissions. You build the role once, assign it to people, and change the job-not twenty individual accounts-when the process changes.
A role is a job, not a person
Name roles after work, not after staff. “Cashier,” “Store manager,” “Buyer,” “Warehouse,” and “HR” survive resignations. “Karim’s access” does not.
Permissions are the small switches behind that job-view products, sell at POS, refund a settled sale, see cost, create purchase orders, manage users, edit roles. The role is simply the set of switches you decided that job needs.
Start from four starter jobs
Most Bangladesh shops and warehouses do not need twenty roles on day one. Four clean ones cover almost everyone, and you customise from there.
- Cashier - sell, look up products and customers, open/close their shift; no cost, no refunds, no purchasing, no settings
- Store manager - what the cashier can do, plus discounts/refunds you trust them with, stock counts, and day-to-day reports
- Buyer - suppliers, purchase orders, receipts, and vendor bills; stock visibility without running the register
- Owner / admin - users, roles, company settings, and the sensitive actions you refuse to leave on the floor
Create or customise a company role
In Workcel, open Roles under Admin. Create a role with a clear name and a short description of who it is for. Then tick permissions by module-POS, Products, Stock, Purchases, Sales, Users, HR, and so on.
Permissions are grouped and nested. A parent item usually opens the screen, and its child items allow specific actions on it. Search when the list feels long. Save only when the ticks match the job description, not when you've “selected everything to be safe.”
Clone when two jobs are almost the same
If Uttara’s manager needs the Mirpur manager’s access plus one extra permission, do not rebuild from blank. Clone the existing role, rename it, then add or remove the few differences.
Cloning keeps your permission set consistent. Hand-building two “almost manager” roles is how one of them accidentally keeps refunds forever.
Guard the permissions that hide mistakes
Some permissions are not about convenience-they are about whether your numbers stay meaningful. Treat them as rare.
- Cost price and purchase pricing - floor staff who only sell should not see what you paid
- Refunds and large discounts - separate from ordinary line discounts on the register
- Stock count apply / quantity corrections - quiet adjustments without a document erase history
- Users, roles, and company settings - only people who hire and set policy
- Deleting products, partners, or lots - harder to undo than creating them
Assign the role to the person
Create or open the user (or employee login) and set their company role. One person, one role for that company. If someone truly wears two hats-cashier on weekdays, buyer on Sundays-prefer the narrower role for daily work and a second login only when you have no choice; dual “super” access is how policy dies.
After you change a role’s permissions, have affected people sign out and sign back in so their session picks up the new list. Until then they may still see yesterday’s access.
Review when the team grows
Roles drift. A “temporary” refund permission stays. A clone accumulates ticks. Once a quarter, open Roles, pick each live role, and ask: would I hire a stranger tomorrow into this job with exactly these switches?
If the answer is no, trim. If two roles differ by one checkbox, merge them. Fewer, sharper roles beat a long menu of almost-identical jobs.