Users and the directory

A Qorionix user is an account that can sign in to Qorionix. That sounds obvious and it is the single most misunderstood thing in the product, because most of what Qorionix shows you is about people in your Microsoft 365 tenant — and those people are not Qorionix users. This article explains what a user record actually contains, what each field is for, and where the line between the two populations falls.

It is written for whoever runs IT. If you only ever add colleagues through Inviting your team you can read the first two sections and stop.

What a user record is

One row in the platform's users table. It holds a login identity — an email address and a password hash — plus a small amount of descriptive information and the flags that decide whether the account works. That is all. It is not a copy of your staff directory, it does not carry a job title unless you put one there, and it has no connection to any account outside Qorionix.

One role per membership is a real constraint worth knowing. Because a membership names a single role, permissions are not additive: a person cannot hold member and a custom role at the same time and get the union. If someone needs two roles' worth of access, you make a third role. The permission model explains why.

The exact status values

The status column is a strict database enumeration. It holds one of exactly eight values, upper-case with underscores, and the database will refuse anything else. New rows default to ACTIVE.

STAGED             imported or created but not yet activated
PROVISIONED        activated but no password set
ACTIVE             fully active
RECOVERY           password reset in progress
PASSWORD_EXPIRED
LOCKED_OUT         too many failed sign-in attempts
SUSPENDED
DEPROVISIONED

Now the unflattering part, and it matters if you are about to build a process around this field. In practice you will only ever see two of those eight. Signing up, and being bulk-imported, both write ACTIVE. Being invited writes STAGED. No other path sets a status: the user-update endpoint accepts a name, an email address and is_active, and does not accept status at all. Only inbound provisioning from another identity system can write the remaining six.

The five user types are EMPLOYEE, CONTRACTOR, VENDOR, PARTNER and SERVICE_ACCOUNT. Every account Qorionix creates for you is written as EMPLOYEE, and no endpoint changes it afterwards, so unless you provision from an external directory the field is a constant. Treat the other four as labels the schema supports rather than as a working classification.

The profile document

Every user carries a profile — a free-form document of keys and values that you choose. There is no fixed key set. It exists so that an organisation can record the attributes it cares about (department, office, cost centre, line manager) without us guessing which ones those are and getting it wrong for everybody else.

One key has meaning to the platform: displayName. It is written by inbound provisioning and is the field an external identity system filters on. Everything else is inert as far as Qorionix is concerned, with one exception — group rules read profile keys, and that is covered in Groups and automatic membership.

You can also declare a profile schema on the Identity → Profile schemas page: a list of attributes with a display name, a type of string, number, boolean or enum, a required flag, permitted values for an enum, and a default. The declaration is stored per organisation and per user type, and it is returned faithfully when you read it back.

A Qorionix user is not a Microsoft 365 user

This is the section that resolves most of the confusion, so it is worth reading slowly. There are two entirely separate populations of people in the product, and they never merge.

Qorionix users

Accounts that can sign in to Qorionix. Typically a handful of people: you, a colleague as backup, whoever picks up alerts, and your auditor. Shown on Identity → Users. Created by signing up, by being invited, or by import.

Microsoft 365 accounts

The people in your Microsoft tenant. Qorionix reads them during discovery and records each one — user, guest, service principal, group, device, administrator role assignment — as an inventory object keyed on the real Entra object identifier, with the user principal name attached so findings can name a real person. These are stored as a point-in-time snapshot per assessment run, not as accounts. They appear in your posture report and in findings, never on Identity → Users.

The two are not linked. There is no column on a Qorionix user that records an Entra object id, no automatic matching, and no background job that reconciles them. If [email protected] exists in both places, that is because the same address was typed twice, not because the platform joined them.

Signing in to Qorionix with a Microsoft account is a separate question again, and it does not change anything above. You can register Microsoft — or another provider — as a federated identity provider, and route an email domain to it so that your colleagues sign in through it. What that gives you is a way to authenticate. It does not import your Microsoft directory, and it does not merge the two populations: a federated sign-in still resolves to a Qorionix user record, and if there is no such record the sign-in is refused rather than inventing one.

Two properties of that design are worth knowing, because both are deliberately more conservative than you might expect. The link between an external identity and a Qorionix user is keyed on the identifier the provider guarantees is stable, never on the email address — an email is a mutable label, and a departing employee's address is routinely handed to their replacement, so an email-keyed link would silently transfer the old account to the new person. And nothing provisions automatically unless you switch it on: creating an account for an unknown sign-in, and attaching one to an existing account that shares its email, are both off by default. A sign-in that resolves to nobody is refused with federation: no Qorionix account is linked to that identity.

Finding a user

The user list is paginated and sorted newest-first, and the sort is not configurable. Search is a fixed set of filters combined with AND rather than a query language, so there is no syntax to get wrong — but there are three behaviours that will surprise you.

• The free-text box is a substring match across email, first name and last name, case-insensitive and unanchored. Searching an matches Anna, Yolanda and finance@….
• Filtering by status or user type is exact and case-sensitive. active matches nothing; ACTIVE matches. An unrecognised value is not an error — it simply returns an empty list, which reads exactly like this person does not exist.
• The largest page is 100. Asking for more, or asking for nothing, silently gives you 50. If you are reconciling a list of 300 people, page through rather than assuming you got everyone.

Search only returns members of the organisation. A user account with no membership row is invisible here even though it exists — which is exactly why an import that appears to have worked can leave you with an empty list.

What to do next

1. Invite your team — the route that reliably produces a working account with a role attached.
2. User lifecycle and deprovisioning — what suspending and removing actually do, and which of them you can undo.
3. Who can see and do what — the three built-in roles and what each one is for.