Users and access
Add a teammate, choose the outlets and modules they can reach, and read the access summary on the Users page.
Organisation → Users is the tenant’s people directory: who is on the team, and what each person can open. Adding a user and editing their access are both owner-only. Everyone else can read the list.
Nothing is invited
Adding a user is not an invitation. Nothing is sent, no message travels, no link is emailed. What happens is that a login is created with a PIN, and you read that PIN out to the person. They sign in with it and change it themselves.
The list
Each row is a person: their full name, and under it their phone or email, whichever they sign in with. To the right sits one summarised access cell and a status chip reading Active or Inactive. The row’s menu deactivates or reactivates the account, and the header counts the teammates.
The access cell is a summary, not the full grant list:
- Outlet grants collapse to one line per role, highest role first. Up to four outlets are named (“Manager · Banjara Hills + 3”); above that the line counts them (“Owner · 11 outlets”).
- Module grants dedupe to one chip per distinct role, spelled in plain words: “POS manager”, “Ops admin”.
- An organisation admin gets its own leading chip reading Admin, because admin everywhere outranks any single module grant.
- Someone with no grants yet reads No access yet.
Click a row to open that person’s drawer, which holds the truth behind the summary.
Adding a user
Press Add user. The form asks for identity, a PIN, and what the person can reach.
| Field | Notes |
|---|---|
| Phone | Leads the form, because the phone is the login. 10 digits, no +91. |
| Full name | |
| The alternative sign-in identifier. | |
| Initial PIN | The 4-digit PIN you read out. It is not remembered anywhere you can look it up again. |
If the phone or email already belongs to someone, the field says so and nothing is created.
The access question, asked once
Access is asked as a short question rather than one grant at a time, on both the add-user form and the drawer, so granting a manager eleven outlets is four answers rather than thirty-three:
- Organisation admin is a switch at the top: full access across every module, wherever the business goes. Leave it off for everyone who is not running the whole estate.
- Outlets is a tick list of your live outlets, with an All outlets tick that takes the lot. It shows a mixed state when only some are ticked.
- Role at those outlets is a single choice, applied everywhere you ticked: Owner, Manager, Staff or Viewer.
- Modules is a tick list of the modules your business has switched on (Procurement, POS, Ops, Reserve, Studio, Smartlinks, Loyalty), each with its own role select beside it. A ticked module is granted at every outlet you chose above.
If you have no active outlets yet, the form says so and asks you to add one first. If no modules are switched on, it says that instead.
Exceptions, and the drawer
The short form cannot say “manager everywhere except staff at one outlet”. For that, open the person’s row. The drawer has three chapters:
- Person: their phone, email and whether the account is active.
- Access: the same short question as above, filled in from what they currently hold.
- Grants: every grant they actually have, in two lists, Outlet roles and Module roles. Each row carries its own role select and a remove button, and a module row names the outlet it applies at (or All outlets). This is where a per-outlet exception is set, and it is the honest reading when the short form has had to round their access off.
Removing an outlet grant also removes any module grants scoped to that outlet, since module access at a place the person cannot reach means nothing. And because the short Access question can only say one role across the outlets it ticked, answering it drops the exceptions the grant list held. The drawer names exactly what a save is about to take away before you commit it.
Saving writes the organisation-admin marker first, then the outlet grants, then the module grants, so a refused change (removing the last admin of the tenant, for instance) lands before anything else is written.