Who can see and do what

Every organisation is created with three roles: admin, member and viewer. For a firm of a dozen or so people those three are usually the whole answer, and you can stop after the first two sections of this article. The rest exists because at some point somebody will ask why they cannot see the audit log, and you will want a precise answer rather than a guess.

The practical point of getting this right is that a role decides how much damage one compromised account can do. Every additional administrator is another account that, if stolen, hands over your whole organisation.

The three built-in roles

`admin` — Full organization access

Everything. Inviting and removing people, changing roles, single sign-on, API keys, billing, credential retrieval, detection-rule authoring, the audit log and the organisation's own lifecycle. The role is granted every permission in the catalogue automatically, including permissions added in future releases, so a new module can never lock the person who owns the organisation out of it.

`member` — Standard member access

The person who actually works the queue. Reads everything a viewer can read, and additionally triages alerts, works incidents end to end, contains a machine, runs and saves investigative searches, builds dashboards, uploads compliance evidence, raises a privileged-access request, uses the assistant, and registers their own phone for push notifications.

`viewer` — Read-only access

Read actions only, and never a read that would expose a secret, a monetary figure or a security-administration surface. Suitable for an auditor, a board member who wants visibility, or a new hire in their first fortnight.

What is deliberately held back from members

Some capabilities are restricted to admin on purpose, not by omission. Each of these is either a way to see something sensitive, a way to spend money, or a way to quietly reduce your own coverage.

How a permission is actually named

You do not need this section to use the product, but it makes error messages and the role editor legible. A permission is a resource plus an action. Resources belonging to a specific module carry a module prefix separated by a colon; the identity and organisation permissions, which pre-date the modules, do not.

siem:alerts.read           View SIEM alerts
siem:alerts.write          Triage and update SIEM alerts
xdr:response_actions.execute   Execute XDR response actions
pam:credentials.read       Retrieve PAM credentials
compliance:evidence.write  Upload compliance evidence
billing:invoices.read      View billing invoices
audit_logs.read            View audit logs
users.read                 View users

The catalogue spans identity and organisation management, SIEM, XDR, PAM, AI, billing, licensing, integrations, compliance, real-time event streams and push devices. The actions are read, write, delete and, for response actions, execute. This article deliberately does not give a total: the catalogue was introduced with 85 permissions and has grown across several migrations since, our own internal documents disagree about the current figure, and it moves again whenever a module gains a surface. Read the list in your own organisation rather than trusting a number written down anywhere — including here. See The permission model for how the catalogue is structured and why it exists.

Building a custom role, and where the console stops

If the three built-in roles do not fit, create a role. The most common genuine need in a small firm is a bookkeeper or office manager who should see the compliance evidence and nothing else, or a contractor who needs the privileged-access side without the identity side.

POST   /api/v1/organizations/{orgID}/roles          roles.write   {"name","description"}
GET    /api/v1/permissions                          (any session) the whole catalogue
GET    /api/v1/roles/{roleID}/permissions           roles.read
POST   /api/v1/roles/{roleID}/permissions           roles.write
DELETE /api/v1/roles/{roleID}/permissions/{permID}   roles.write

Two things to know before you run those. roles.write is one of three permissions that require a fresh second factor on every call, so a script holding an API key cannot do this at all — Step-up authentication explains why and what to do instead. And editing a role also requires your own role to be named admin or delegated_admin; holding the permission is not sufficient. A refusal reading action requires elevated delegated role is that check, not a missing permission.

1. 1

   Name it after the job, not the person

   "Compliance reviewer" survives the person leaving. "Sarah's access" does not. Write a description; the field is shown in the list and to whoever inherits your job. Note that the name is matched case-sensitively by the seeding logic, so a role called Admin is not admin and starts empty — which for a custom role is what you want.

2. 2

   Read the catalogue before you pick

   GET /api/v1/permissions returns every permission the platform defines, and it needs no permission of its own — any authenticated user can read it. That is itself worth knowing: the catalogue is not a secret, but the fact that anyone can enumerate it is a small piece of reconnaissance you cannot switch off.

3. 3

   Start from read-only and add

   Grant the reads the person needs, save, and let them use it for a week. Add the writes they turn out to need. This takes slightly longer than granting everything and trimming later, and it is the only order that reliably ends up minimal.

4. 4

   Assign it at invitation time, or over the API

   The Invite dialog on Identity → Users has a Role selector listing your roles by name; that is the one place the console assigns one. For somebody who already exists, use the members API. Then have them confirm they can do their job — a role that is too tight produces a support conversation, and a role that is too loose produces nothing at all, which is why nobody catches it.

One limitation you need to know about

In practice this affects two situations. The first is an accountant or IT contractor who works with several Qorionix customers; they need a separate login per client for now. The second is somebody in your own firm who accidentally created their own organisation during signup and then joined yours as well. For that second case, remove the membership they do not need and the problem goes away.

We would rather tell you this than have you spend an afternoon on a permission problem that no amount of role editing can fix.

Checking and changing someone's access

Identity → Users is the screen. It lists every member with their type, status, whether a second factor is enrolled and when the account was created, and it carries a search box over name, email and status. Four figures sit above it: Active, Inactive, MFA enrolled and MFA coverage. The last of those is the single most useful number on the page, and it is the one to check before you tell an auditor that everybody has a second factor.

There is no detail panel. Each row carries exactly three actions, and each confirms before it acts:

**Reset MFA**

Confirms with Reset MFA for {email}?, then clears their authenticator and every remaining recovery code. It does not remove a passkey and it does not sign them out. Requires users.write.

**Revoke sessions**

Confirms with Revoke all active sessions for {email}?. Use it whenever the reason for a change is a concern rather than a promotion — changing a role does not end an existing session.

**Suspend**

Confirms with Suspend {email}?, marks the account inactive and locks it far into the future. Greyed out on an account that is already inactive. It does not end their sessions; do both.

What is not on that screen, so you do not go looking: a per-user role change, group membership, profile fields, API keys held in that person's name, a per-user session list, a per-user audit view, and a pending-invitation list. Each of those is an API call today. The organisation-wide equivalents that do exist are Identity → API Keys and Identity → Audit.

When someone leaves

1. Press Suspend rather than deleting anything. The account stops working immediately and their history stays attached to a real name.
2. Press Revoke sessions on the same row. Suspending an account does not end a session that is already open, and thirty minutes of idle time is a long time on a laptop somebody still has.
3. Open Identity → API Keys and revoke any key issued for them. A key outlives a person and nobody thinks to look. Do not reach for the deprovisioning API as a shortcut — see API tokens for what it does to every other integration in your tenant.
4. If they held admin, filter Identity → Audit to their user id and read their last month. This is not an accusation; it is how you find the undocumented change that breaks something in March.

If a role change or a 403 does not behave the way this article describes, tell us and include the exact permission name from the error. How to get help lists what makes a ticket answerable on the first reply.