How do roles, permissions and the audit trail work?

The roles, permissions and audit trail module is the core layer that answers, on every panel screen, “can this user see this” and “who made this change.” Every other module — customers, accounting, trips, the assistant — borrows its access checks from here; no module invents its own permission logic.

Users and roles

The Users and permissions screen has two tabs. The Users tab is your team list; every user carries a role, a rank and a status (active/suspended). The Roles tab is a master-detail layout: a searchable role list on the left, the selected role’s detail on the right — even a company with fifty roles and a hundred users keeps this as a vertical, searchable list rather than a table that scrolls sideways. A role’s detail splits into three tabs: Permissions (grouped module by module), Members (users holding this role) and Appearance (the role’s name and colour).

Permission scope: all and own

A permission can be granted company-wide (all) or limited to a user’s own records (own). A driver’s “I can see my own trips” permission, for instance, is own-scoped — they cannot see a trip they were not assigned to; an operations manager holding the same permission as all sees every trip in the company. This split repeats in every module and is filtered by the same rule all the way down to dashboard widgets, lists and search results — an amount hidden on one screen never leaks out through a report or an export either.

The rank gate

Separate from role, there is also rank, and the two answer different questions: role decides “what actions can be taken”, rank decides “who can act on whom, and who can grant which rank.” A user can act on someone with a lower rank but never on someone equal or higher — this is how a company always keeps at least one owner, with no extra check needed. Ownership itself (the owner rank) cannot be handed off; an owner can only assign a lower rank, never their own.

The audit trail

The Staff tracking screen holds two things together: who currently has a session open (with the option to close that session remotely) and the company’s entire audit record. Every mutation — a user invited, a role’s permissions changed, an invoice issued — leaves a row here, carrying who did it, when, and what changed. Audit events are drawn from a closed dictionary — a row cannot be written under an event name that is not in it, which keeps the audit record from filling up with arbitrary text.

Full authority and readable audit rows

A “full authority” flag on a role can only be granted by the company owner (rank 10) — it means that role automatically holds every permission in the company, and it is deliberately kept narrow. Every audit row does not just say “what happened” — it also carries which record, which parent record (a passenger row on a trip, say) and which fields were touched, so reading one row answers “who changed what, inside which record” without needing a second screen.

Example

Picture a company where someone on the accounting team has a “Accounting” role scoped own, seeing only their own branch’s invoices. When they try to look up another branch’s invoice, the result comes back empty — they are not told they are blocked, the record simply behaves as if it does not exist. Later that day, a manager widens their role to all; that change shows up permanently on the Staff tracking screen as a “role permission changed” row, with which manager did it and when.

How it works in Rotenta

1. From the Users and permissions screen’s Users tab, a new person is invited; their role and, if relevant, their rank are chosen at that step.
2. From the Roles tab, a role is selected and its Permissions sub-tab is used to check permissions module by module; scoped permissions get an own/all choice.
3. The Members sub-tab shows who holds this role, and a new member can be added there.
4. To temporarily stop a user, they are suspended from the Users tab; if their session is open, it can be closed instantly from Staff tracking.
5. Closing every open session company-wide — say, after a suspected access issue — can be done in a single bulk action.
6. Every change lands automatically in the Staff tracking audit list, which is searchable and filterable.

You can read about the consent side of this permission system in consent management, how it applies to sensitive fields on a customer card in customer management, and how the assistant inherits this exact permission set in AI assistant. The full picture of how this core layer relates to the rest is in our module guide; for a role template that fits your team structure, get in touch.

Frequently asked questions

If I change a user’s role, does it rewrite their past actions?

No; the audit record keeps exactly what was done under which permission at the time — a role change only affects access from that point forward.

Where does the own/all scope apply?

Everywhere a permission check runs — lists, dashboard cards, search results and exports all apply the same scope rule.

Can an owner hand their rank to someone else?

No; ownership cannot be transferred — an owner can only assign a rank lower than their own, which is how a company always keeps at least one owner.

Can an event name outside the audit dictionary be written to the log?

No; audit events come from a closed dictionary, and an attempt to write a row under a name that is not defined there is rejected.

If we notice suspicious access, can we close every session at once?

Yes; from Staff tracking, every open session company-wide (except your own) can be closed in a single action.