Team & permissions

One system does not mean everyone sees everything.

Workspaces, branches, teams, people, roles, devices, and audit entries — the controls that decide who can read a customer's history, who can create an invoice, and which actions need a supervisor before they happen.

See NoxOrigin in action Book a walkthrough

The problem

Growth breaks systems in a specific way: the person who set it up knows everything, and everyone else has been sharing their login. That feels efficient until a resignation, an audit, or a dispute, at which point there is no way to tell who did what, no way to remove one person’s access without locking out everyone, and no way to stop a delivery role from creating an invoice. A single shared credential also destroys accountability at exactly the moment it matters — the counter, the gate, the field. This is not primarily a security product; it is the administrative work that every growing business defers until the moment it becomes urgent, and the awkward part is that doing it properly is uncomfortable, because some of the people who currently have everything are the ones who will lose something.

Works with: Customer → Opportunity → Quote → Project → Work → Invoice → Payment

How you use it

A working day, start to finish.

Open a workspace, branch, store, or team
The organisational structure is set up first, because a permission only means something relative to which part of the business it applies to. Workspaces, branches, stores, and teams let a group with genuinely separate operations keep their data apart, while a consolidated view reads from the same information rather than from a monthly export. Where a group should be one business with many counters, and where it should be many workspaces, is a decision to make deliberately rather than a default to inherit.
Assign roles and scope what each person can do
People, roles, and permissions that apply per workspace decide what each account can read and change. Delivery members get access to client and project context and to creating, updating, and changing the status of tasks — the work itself, not the money. Quotes, invoices, payments, and discount approval are separate, explicit permissions, so the role that runs a project cannot by default raise a document against it. Viewer access derives from what that workspace allows to be read, and stops there.
Give counter and field staff a PIN instead of a shared login
Staff who need the system for one function sign in with a PIN tied to their own person rather than sharing one account. This is the mechanism that makes a shift, a scan, or a counter action attributable to a human. PIN-based staff access also solves the practical problem of a shared device: the person on the till is identifiable even though the device is not theirs.
Route approvals and supervisor overrides deliberately
Actions that carry financial or operational risk can require a manager approval, and a supervisor can override a blocked action when the situation demands it. The important property is not that overrides exist — it is that they are written down, so a later reviewer can see that an override happened, who made it, and against what. An override nobody wrote down is the same as having no control at all.
Inspect activity, audit, exports, and developer controls
Audit entries and activity history give the answer to who changed what and when, and exports, migration, and backups mean the data is not only held hostage to this system. For teams building on top, API access, OAuth, and webhooks expose the same information under the same permissions rather than through a side door. Offline queues and sync recovery describe the honest behaviour when a device is disconnected: work is queued and recovered rather than lost, with the state visible to whoever is responsible.

What changes

What is different in practice.

A resignation no longer requires guessing which shared login was used, because actions carry a person.

Access can be scoped to one workspace or branch, so a group of sites is not one all-or-nothing switch.

Money actions are gated by explicit permission, so a delivery role cannot raise an invoice by default.

Overrides and approvals are recorded, which makes them reviewable instead of invisible.

The data is exportable and backed up, so changing system is a decision rather than a dependency.

Product proof

From the current NoxOrigin app.

Real captures, not marketing mockups. Configuration and availability are confirmed during setup rather than promised on a page.

NoxOrigin settings Members screen listing workspace members and their assigned roles. — Who is in the workspace and what each of them is actually allowed to do.Current NoxOrigin app — Members and roles.

NoxOrigin workspace settings screen showing workspace identity and configuration. — The workspace record itself — identity, plan and the state that governs everything else.Current NoxOrigin app — Workspace.

Sessions and credentials for the person signed in, not just for the workspace.Current NoxOrigin app — Security.

People → roles → what each person is allowed to do

What this area holds, and what it connects to.

Who uses it

Roles, and what each one needs.

OwnerFull control over workspaces, people, and money, and the ability to see who exercised it.
AdminTo configure people, roles, catalog, and workflows without being the only person who can fix anything.
ViewerTo read what the workspace permits and nothing more — a genuinely useful role, not a demotion.
Members and delivery staffTo do their own work — client and project context, task creation, updates, and status changes — without being handed money permissions.

Scenarios

Three ordinary situations, described honestly.

These are illustrative workflows, not customer results. We do not publish outcome claims without approved customer material.

The person who knew everything

One employee had been the system since the beginning: they set up the accounts, the catalog, and the pricing, and because the permissions were not separated, they could also change anything. Restructuring this is uncomfortable work, because the person losing access is often the person who knows the most. The practical approach is to write the role down, transfer what only they know, and then apply it — permission cleanup is uncomfortable precisely when it is most needed.

The delivery person who could raise an invoice

A team member who was genuinely excellent at delivery was also, by default, able to create an invoice and record a payment, because everything sat under one role. Splitting that means members keep access to client and project context and to creating, updating, and changing the status of tasks, while quotes, invoices, payments, and discount approval become explicit permissions held by admin and owner. Nothing about their actual job is taken away.

The device at the counter

A tablet stays on the counter and is used by whoever is on shift. With a shared login, the day’s sales are attributable to an account rather than a person, which defeats the purpose of tracking the shift at all. PIN-based staff access ties each transaction to the individual who rang it up, so the shift has one owner and the audit trail is worth reading.

Before you start

The parts that need a decision.

Every part of NoxOrigin has awkward edges. Naming them now is cheaper than discovering them in month two.

Role sprawl is the normal failure mode. A role per person, created to solve one problem, is how a workspace ends up with forty roles nobody can describe. Review the role list periodically and collapse the ones that exist because someone was in a hurry.
PIN discipline is a real operational task. A PIN on a sticker next to the till is not access control, and a PIN shared between two staff on the same shift reintroduces exactly the problem PINs were meant to solve. Set the policy when you introduce it.
Shared devices complicate removing someone. If a device is used by many people, removing a person must not mean physically reclaiming hardware, and the person — not the device — is what should carry the identity.
Offline queues and sync recovery need a named owner. Queued work that nobody reconciles after a device is out of range for a week is not resilient, it is postponed; someone should be responsible for checking that recovery completed.
Platform administration is separate from the permissions inside a workspace. Deciding who can administer the system is a smaller and more consequential decision than the roles set for each workspace, and it deserves a deliberate review rather than an inherited default.

Questions

What people ask before they start.

How are permissions actually decided?

Per action, within the workspace. A verified example of the pattern: updating a task and changing task status are open to member, admin, and owner, while creating a company, creating a quote, creating an invoice, recording a payment, and managing project members are denied to member and allowed to admin and owner. Viewer access derives from what the workspace allows to be read. The full split is published in the POS employee permission matrix.

Do staff need their own accounts?

For counter and field roles, PIN-based staff access gives each person their own identity without the friction of a full credential. That is what makes a shift, a scan, or a counter action attributable to a person rather than to a device or a shared session.

Can I lock a role out of money actions?

Yes — that is the point of separating them. Quotes, invoices, payments, and discount approval are explicit permissions, so a delivery role can run the project without being able to raise a document against it.

Is there an audit trail?

Audit entries and activity history record who changed what and when, including manager approvals and supervisor overrides. Reviewing an override later is possible because the override was recorded rather than performed quietly.

Can I get my data out, and do you support SSO or HR systems?

Exports, migration, and backups are supported, and API, OAuth, and webhooks expose the same information under the same permissions. This is not a single-sign-on replacement for your other systems, and HR, payroll, and attendance are out of scope — NoxOrigin is built for the work and the money that goes with it, not a people-management system.

Where to go from here.

See NoxOrigin in action See pricing

One system does not mean everyone sees everything.

A working day, start to finish.

Open a workspace, branch, store, or team

Assign roles and scope what each person can do

Give counter and field staff a PIN instead of a shared login

Route approvals and supervisor overrides deliberately

Inspect activity, audit, exports, and developer controls