Security & access
A general manager runs their store completely and never sees the group's money.
That sentence is the whole argument of Nexora's access model, and it is enforced before the page renders rather than by hiding buttons. When a store manager signs in, the platform does not load the group's financials and then decline to draw them — the query never asks for them.
Why that distinction matters more than it sounds
Most software calls this "role-based access" and means the interface hides things. That version fails twice: it does not survive someone typing a URL directly, and it is not something a franchisee will accept when their numbers sit in the same database as a competitor's.
In Nexora, a role is not a set of hidden buttons. It is the scope the session is issued with, resolved at authentication and unchangeable downstream. Identity, role and store list are decided at sign-in; everything the person subsequently sees — dashboard scope, store selector contents, report coverage, what an exported PDF contains — follows from it.
Sign-in: there is no password to steal
Restaurant teams turn over quickly and share devices. A password model in that environment reliably produces written-down credentials and shared logins — which makes the audit log fiction. Removing the password removes the artefact.
- Everyone opens the same URL. There is no separate admin portal and no separate franchisee portal to discover.
- They enter an email address. The identifier is the address, not a username invented for the system — which is what lets access be assigned to someone before an account exists.
- A six-digit one-time code is sent to that address. Short-lived. Nothing persistent is stored on the user's side, so there is no credential to rotate, reuse or lose. Control of the mailbox is the factor.
- The code is exchanged for a scoped session. At this moment the platform resolves the person's role and store list.
- They land on their own altitude. An executive lands on twelve stores. A general manager lands on one. Same door, different building.
The practical consequence. When someone leaves in March, revoking them in Command Center removes their access everywhere at once — including any report already scheduled to them, and including the phone in their pocket, because there is no native app holding a cached session.
Role is one axis. Store is the other.
A role says what someone may do. It says nothing about where. The two are assigned together, per store, which is what allows one person to hold genuinely different standing in different parts of the business — an area manager for their own region and a store manager at a location they are covering.
| Assignment | Effect | Financial visibility |
|---|---|---|
| Super admin · all stores | The estate as one set of books. Access administration, the permission grid, integrations and API keys. | Full — net sales, prime cost, COGS, wage rates, budget variances, everywhere |
| Admin · a named set of stores | Full operational control and cost visibility for those stores only. The store selector contains nothing else. | Operational — labour costs, hourly rates, overtime metrics for the assigned region |
| Store manager · one store | The whole operating surface for that location: schedule, team, attendance, local reporting. | Store level — store labour totals, schedule budget versus actual. Not the group's money. |
The three business titles most groups recruit for map straight onto these tiers: Executive / CEO / CFO to super admin, Multi-Unit / Area Manager to admin, and Store General Manager to store manager. The grid itself is configurable under Settings → Admin → Permissions; super admin holds full access and cannot be reduced below it.
What scope carries with it, outside the interface
Scope is not only enforced on screen. Anything the platform emits on a person's behalf is built from the same entitlement.
Scheduled reports
Labour, dashboard and P&L summaries are built from what that person can see on the day they go out — never more. Store coverage follows access automatically, so locations someone gains or loses are added and dropped without anyone remembering to update a distribution list.
NexAI
The question box answers from your own ledger, scoped to the same entitlement. A store manager asking about group labour cost is not refused an answer they can see anyway — the data was never in scope to answer from.
Exports and API
Excel and PDF exports contain the same scope as the screen they came from. API keys, issued under Settings → Developer, are bound the same way — and the product is explicit that most customers never need one.
Data protection, stated plainly
Data is encrypted in transit and at rest, and the sign-in page says so rather than burying it in a policy nobody opens. Beyond that, the honest list of what protects a restaurant group's numbers here is short and architectural:
- No stored password — nothing to phish, reuse, or lose in someone else's breach.
- Scope at authentication — a URL typed directly does not widen what the session can query.
- Audit log — every assignment, supersession and revocation, with timestamp and actor. Reviewing it takes ten minutes a month and is what keeps an access list honest.
- Read-and-reply review connections — each store's Google Business Profile is connected once, per store. Nexora cannot delete a listing, transfer it, or change who has access to it, and it can be disconnected at any time from either side.
- Human approval on extraction — uploaded bank statements are read line by line and proposed as expenses. Lines the extractor is unsure of are held pending for a person to approve, reject or reclassify. It never posts itself.
Before you connect a point of sale to anything, get four answers in writing: where the data is hosted and by whom; the retention and deletion terms after termination; the data-handling and model-training position; and the support response targets. We will give you ours on the call. If a completed third-party audit report or a signed DPA is a procurement gate for your group, raise it in the first ten minutes rather than in week six — it is a genuine yes-or-no and neither of us benefits from finding out late.
Rolling access out across a group
This order avoids the two failures that usually follow a permissions rollout: people locked out of work they are accountable for, and people quietly holding access nobody remembers granting.
- Fix the store list first. Locations, departments and roles under Settings → Scheduling. Scope is assigned against stores, so the store list has to be right before anything is granted.
- Grant the super admins deliberately. This tier sees the group's money and can change the permission grid. Seven is a defensible number for twelve stores; seventy is not.
- Assign area managers by region. Admin role, scoped to the stores each is accountable for — not all stores "for convenience", which is how the model erodes.
- Assign one GM per store. Store manager role, single store, the whole operating surface for that location.
- Clear the unlinked POS list before trusting labour figures. Until POS employees are mapped, labour cost coverage sits below 100% and every labour ratio reads low.
- Set labour budgets per store. Without a budget there is no variance, and the dashboard will tell you so.
- Turn on scheduled reports, so the people who need the numbers stop needing to remember to look.
- Review the audit log monthly. Ten minutes, once a month.
Bring your worst-performing store
Twenty minutes, your own POS data, no deck. If we cannot show you something you did not already know, we will say so and leave.
Book a 20-minute demo