Permissions, audit and API access
AWS-style access control down to individual fields, an append-only audit trail on every record change, and scoped API keys for services and integrations.
Part of AxisIQ's single business model — The governance layer (across every layer). How the layers fit.
The question every owner eventually asks is not "can the software do this?" It is "can I let that person near it?"
AxisIQ answers that with one engine that every single path through the platform must pass — your staff, the assistant, your flows, your scheduled jobs and your API integrations. There is no privileged side door.
How permissions work
Permissions are grants, written as statements: an action (records:update, drive:write, accounting:post), a resource (all types, one type, one Drive space, one content space), and optional conditions. Statements live on groups; a person's effective permissions are the union of their groups'.
Three rules govern the result, and they are the ones you would want:
- An explicit deny always wins. You can grant a team broad access and carve one thing out with confidence.
- Otherwise an allow wins.
- Otherwise, no. Someone in no group can do nothing. Access is something you give, never something you forget to take away.
The organisation's owner holds every permission and can never be removed or demoted, so nobody locks the business out of itself. Anyone else who needs everything gets a role that grants it — visible on the Roles page like any other grant.
Down to the field
Permissions do not stop at "can see orders". A statement can mask individual fields, and the masking holds everywhere: the field is stripped from record reads and forms, left out of CSV exports, and returned as NULL in analytics queries — so it cannot be recovered with a clever SELECT.
That is what makes it safe to give a warehouse team, a part-time bookkeeper, an agency or a supplier real access to real screens without exposing cost prices, margins or salary data.
Machines get identities too
Integrations usually authenticate as "the system" and can therefore do anything. Here they are service accounts: non-human members that join groups exactly like people, carry an API key, and are limited to the same statements. They can never be the owner, keys are shown once and stored hashed, and a key only works on the organisation it belongs to.
The audit trail records them as themselves — so an unexpected change is attributable to that integration, not to a mystery.
There is a third identity too: the anonymous one, used by public function endpoints and public content delivery. Grant it nothing and public URLs return nothing. Everything published to the world is published because someone deliberately granted it.
The audit trail
Every record mutation is appended to a permanent log: who did it, when, which record, and what changed — before and after. It captures the change at the point it happens, so it covers edits made by a person in the UI, by the assistant, by a function, and by an API key alike.
It is append-only, gated by its own read permission, and visible right where you need it — the Activity tab on a record answers "who changed this price?" without anyone opening a database.
Simulate before you break something
Permission systems fail when nobody is sure what a change will do. The Team app includes a simulator: pick a person and an action, and it tells you the answer the engine would give and why. Test the rule before you save it, not after the phone rings.
Field-level permissions and API access are included on every plan — see pricing.