Role-based access for a business where more than one person uses the system.
NoxOrigin separates workspaces, branches, teams, people, roles, and devices, with workspace-scoped permissions, PIN-based staff access, and an audit history of what changed and who changed it. It is the administrative work every growing business defers until it becomes urgent — and it becomes urgent at the worst possible moment.
How a shared login becomes a real 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, a dispute, or an audit.
Accountability disappears at the counter
A tablet stays on the till and is used by whoever is on shift. With a shared login, the day’s sales belong to an account rather than a person, which defeats the purpose of a shift record.
Money actions come attached to delivery jobs
When everything sits under one role, an excellent delivery person can also create an invoice and record a payment — not through any intent to do so, just because nobody separated the permissions.
One person can fix everything
A workspace where only the original administrator can change structure is a single point of failure, and it is usually also the busiest person in the business.
Permissions are never reviewed
Roles get created to solve one problem and never touched again, so within a year nobody can say what half of them are for. The fix is a periodic review, which is a habit rather than a feature.
Setting roles up in a defensible order
Scope, then role, then money permissions, then the staff who use it. Doing it the other way round means starting with the hardest conversations.
Model the scope before the role
Workspaces, branches, stores, and teams come first, because a permission only means something relative to a scope. Deciding this deliberately beats inheriting a default.
Write the role down
One role per job, not per person. Role sprawl — a role created to solve one problem — is how a workspace ends up with forty roles nobody can describe.
Split the money permissions out
Quotes, invoices, payments, and discount approval are explicit. A delivery role keeps client and project context and the work itself, without being able to raise a document against it.
Give counter staff a PIN
Identity without a full credential, so each transaction belongs to the person who rang it up rather than to the account on the device.
Turn somebody off cleanly
Deprovision the person, not the device everybody shares. Audit history shows what that person did while they were here.
Review the roles periodically
Collapse roles that exist because someone was in a hurry, and check that access still matches what each person actually does this quarter.
What the published split actually says
Concretely, so the conversation is about your people rather than about the product. A verified example of how the split is drawn: member, admin, and owner can update a task and change task status; 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. Delivery access is scoped to delivery actions — reading client and project context, creating and updating tasks, changing status — while pipeline and money actions stay gated separately.
Where this is the wrong tool
Access control products vary enormously in what they actually govern, so the boundary is stated rather than implied.
It is not an identity provider
No single sign-on, no directory sync, and no password-policy engine for the rest of your stack. This governs what people can do inside NoxOrigin, not how they authenticate everywhere.
It is not a people-management system
HR records, payroll, attendance, and shift rostering for HR purposes are out of scope. A shift in Commerce exists to make counter activity attributable, not to run payroll.
It does not manage devices
Kiosk lockdown, mobile device management, and remote wiping are not part of this. What a device is is recorded; what it is allowed to do is your IT decision.
It is not field-level masking
The split is role-level: which actions a role may perform and what the workspace allows to be read. Column-level or cell-level visibility is not something this model provides.
Role-based access questions
How are permissions actually decided in NoxOrigin?
Per action, inside the workspace scope. A verified example of the split: 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, and stops there.
Do counter and field staff need full 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 — which matters when the till belongs to the business rather than to the person standing at it.
Can we remove one person without locking everyone else out?
Yes, and that is the point of modelling people separately from the shared device. Removing an account is a per-person action rather than a per-login action, so the person who set everything up no longer has to be the person who can unlock everything. Shared devices complicate deprovisioning, which is why identity lives on the person record, not the hardware.
What happens if the person who knows the system leaves?
Access can be scoped and audited rather than inherited. Audit entries and activity history record who changed what and when, including approvals and overrides, so the knowledge that used to live in one person becomes something the team can read. It is still an uncomfortable piece of work — the person losing access is often the person who knows the most — but it is a transfer, not a rescue.
Does this include SSO and HR integration?
No. This is not a single-sign-on replacement for your other systems, and HR, payroll, and attendance are out of scope. Exports, migration, and backups are supported, and API, OAuth, and webhooks expose the same records under the same permissions rather than through a side door.
Can it mask individual fields for certain roles?
Not as a field-level rule. The published split is a role-level decision about which actions a role may perform and what the workspace allows to be read. If you need specific fields hidden from specific roles — a salary figure, a margin column, a personal contact — raise it during the walkthrough rather than assuming it is included.
Write the role down before you hand anyone access.
Bring a list of what each person actually does. We will turn it into a small, describable role set and tell you where the awkward decisions are.