Set up team permissions, down to the field

Give each role exactly the data it needs: groups, allow/deny policies, field-level masking and an audit trail — set up in an afternoon, not a quarter.

By the end of this guide each person on your team can do their own job in AxisIQ and nothing else: a warehouse group that moves orders along but cannot delete them, a finance group that owns invoices and the ledger, cost price invisible to everyone in sales, and an API key for your integration fenced in exactly like the people around it.

Do it early, because permissions here are not a layer painted over the screens. One set of rules decides every request — from the dashboard, an API key, Ask Axis, a flow or a public form — so a rule you write once holds on every route into your data.

The model, in one paragraph

People belong to groups. A group carries statements, and a statement is four things: allow or deny, the actions it covers (records:read, records:update, accounting:post), the resources they apply to (everything, or one object type such as invoices), and optionally a condition or a list of fields to withhold. Someone's access is the sum of the statements across their groups, with two rules on top. A deny wins over an allow, whichever group each came from. And a person in no group has no permissions at all — the starting balance is zero, so every capability someone holds is one you decided to give. The workspace owner is the one exception: they skip the evaluation entirely. Anyone else who needs everything gets a group that grants it, visible like every other grant.

What you need first

• The right to manage the team. The workspace owner — whoever created it — has it.
• Your team's email addresses.
• An answer to one question: who must not see cost price, margin or supplier terms? That answer drives most of the work below.

If your object types and fields are still moving around, settle those first — the getting-started guide walks through it. Permissions are much easier to write against a structure that has stopped changing.

Step 1 — Invite the team (they arrive with nothing)

Invite people from the Team & Permissions app. An invitation can name the groups the person lands in when they accept; leave that empty and a new member arrives with no access to anything: they can sign in, and they see an empty workspace.

That is deliberate. The safe state is the default, so an invite sent in a hurry cannot leak anything before you have decided what that person should reach.

Step 2 — One group per function, not per person

Name groups after the work rather than after people: Sales, Warehouse, Finance, Bookkeeper, Read-only. Someone who does two jobs joins two groups and their access is the sum — the behaviour you want when the packer also answers the phone.

Resist a group per employee: five well-named groups stay legible a year from now, twenty personal ones do not.

Step 3 — Write the statements

Edit each group app by app in plain words — no access, can view, can edit, full control — and open the statement editor under Advanced for anything finer, such as a single object type or a deny. A first cut for an operations team usually looks like this.

Two habits. Grant against a named object type rather than against everything, so a type you add next month is not silently in scope. And use a deny when the exception is shorter than the list — broad access with one type carved out still reads clearly a year later; nine enumerated types do not.

Step 4 — Hide the fields that should not travel

A statement can be narrowed a second way: alongside its actions and resources, it can name fields to withhold. Put cost_price and margin on the Sales group's withheld list and those values stop reaching that group anywhere — the record screen omits them, a CSV export comes out with those columns empty, and reports and dashboards return blanks rather than numbers. The masking applies to the data, not to the screen, so there is no route around it.

The same holds for Ask Axis: every tool call the assistant makes carries the permissions of the person chatting, so a withheld field never reaches it, and it cannot report a number it was never given.

This is what lets you widen access rather than ration it: an outside accountant, a temp on the packing bench or an agency can work in the real screens, on live data, with the commercially sensitive columns absent.

Step 5 — Prove the rules before anyone hits a wall

Team & Permissions has a Simulator tab. Give it a person, an action and a resource, and it returns the decision and the reason behind it, so a surprise traces back to a line you can edit.

Run two checks after every change: one thing that must work, one that must not. Warehouse can update orders; Warehouse cannot delete orders. The failure people actually hit is not a rule that is too loose but one that turned out quietly too tight, found at 6pm by a packer who cannot ship.

Step 6 — Give integrations an identity of their own

A script that signs in as the owner is a standing hole in everything above. Use a service account instead: a non-human member of the workspace, assigned groups the same way a person is, authenticating with an API key rather than a password.

Three properties matter. It can never be the owner, so the ceiling on any key is whatever its groups say. The key is refused outside the workspace it was issued in. And it is shown once, at creation — put it in your secret store there and then.

Rotation is a key operation, not an account operation: revoke the old key and issue a new one on the same account. Its groups and its history stay intact, so nothing has to be rebuilt.

Automations inherit permissions, they do not escape them

Flows run with the permissions of the person who built them, so a flow cannot do what its author could not do by hand — tighten the author's groups and every flow they own tightens with them. Functions run with the permissions of whoever invoked them. Public surfaces — a published form, a public function endpoint, delivered content — are governed by an explicit anonymous group that begins empty: until you write a statement there, an unauthenticated visitor is refused at every URL.

So reviewing who can do what is one job, not six. No route into your data carries rights of its own.

What the audit trail gives you

Every record mutation adds a line to an append-only log: the actor, the time, the record, and the field values on either side of the change. Later edits never rewrite those lines.

Changes made through Ask Axis or by an automation are logged the same way, against the identity that made them, so an unexpected edit is attributable rather than anonymous. Reading the trail is its own permission, so an auditor can be given the history without a single write action.

The honest limits

Permissions are decided per action, per resource and per field — not, in general, per row. A statement can carry a condition, but conditions read attributes the system stamps on a record — its owner, its type, when it was created — not arbitrary fields you define. A rule of the form "only the customers whose region field says West" is not something to plan around today.

You can keep sales out of the ledger and out of cost price completely, which covers most of what people mean by restricting the team. Giving two reps the same customer list and a different slice each, by a field you maintain, is not there — that split needs separate object types, or separate workspaces, today.

The owner bypasses all of it, masking included, and a group that grants everything comes close. Granting someone everything because a permission was inconvenient undoes the rule you wrote, and it is the most common way a careful setup stops being one. The owner can never be removed, so the workspace can never be locked out of itself.

FAQ

Can I stop one team from seeing cost prices? Yes — add those fields to the withheld list on that group's statement and they leave the group's record screens, exports and reports. They also leave anything Ask Axis answers for them, because the assistant reads under the permissions of the person asking.

Do these permissions apply to the API as well as the interface? Yes, the same rules decide both. API keys belong to service accounts that join groups the way people do, so a key can only do what its groups allow, only on the workspace it was created in, and never as the owner.

Can AxisIQ restrict access row by row — only my own customers? Not as a general rule, no. Access is decided per action, per resource and per field, and conditions read only the attributes the system stamps on a record, not fields you define — so separating two people's data today means separating it by object type or by workspace.

How many groups does a team need? Usually three to five, named after functions rather than people. Anyone with two roles joins two groups and gets both sets of permissions, which is easier to reason about than one group per employee.

What happens when someone leaves? Remove them from their groups and their access ends, because nothing is granted by default — but their entries in the audit trail stay, since the log is append-only. For an integration being retired, revoke its key rather than deleting the service account.

More on the mechanics behind all of this: permissions, audit and API access.