Users ​
The Users screen is the management screen where you, as an organization administrator, manage your organization's staff. You invite new users or create them directly, search and filter the list, activate or deactivate accounts, mark who is a practitioner, and assign roles and teams. The screen is intended for administrators with permission to manage users.
Overview ​
| Route | /organization/users (overview), /organization/users/:userId (detail) |
| Audience | Organization administrator |
| Required permissions | users.read (view); users.create (create), users.invite (invite) and users.update (edit) for specific actions |
The overview lists all users in a table with name, email address, phone number, status, role and team. Practitioners are marked with a label. At the bottom — if you have the users.invite permission — there is a section with pending invitations.
A user can join the organization in two ways: you invite someone (the user sets their own password via an email) or you create the account directly. The detail data — status, practitioner flag, roles and team — is managed on a user's detail screen.
How it works ​
A few rules and states sit behind this management screen and determine what you see and what you can do. Understand them before you create, invite, or revoke users.
Inviting versus creating ​
There are two ways to add someone, with one important difference in who sets the password:
| Method | Who sets the password | When to choose it |
|---|---|---|
| Invite | The user themselves, via an invitation link in an email. | The usual route: the user activates their own account and chooses their password. |
| Create | No one up front; you record the account directly. | When you want to fill in the account completely right away, without waiting for the user. |
An invitation does not yet create a full account: the account only comes into being once the invitee accepts the invitation.
The invitation state machine ​
An invitation moves through fixed states. Only a pending invitation can be accepted; all other states are end states.
| State | Meaning | Can still be accepted? |
|---|---|---|
| Pending | Sent, not yet used. | Yes, as long as it hasn't expired. |
| Accepted | The user has created an account. | No — the account already exists. |
| Expired | The validity period has passed. | No — send a new invitation. |
| Revoked | An administrator cancelled the invitation. | No — send a new invitation. |
Once accepted, expired, or revoked, an invitation cannot be "reactivated"; you simply send a new one.
Removing access: deactivate versus revoke versus delete ​
Which action you use to take away someone's access depends on the state of the account:
- Revoke invitation — only possible while the invitation is still pending. The link expires and no account is ever created. Use this when someone was invited by mistake.
- Deactivate — for existing accounts. The account is kept within the organization (and with it the history and links to dossiers), but the user can no longer sign in. This is reversible: check Account is active again to restore access.
- Delete — Scrivio deliberately has no button to hard-delete an existing user account. Because a user can be linked to dossiers, appointments, and audit logging, deactivating is the intended way to permanently remove access without breaking that history.
Conditional practitioner fields ​
The profession code, AGB code, and BIG registration fields belong to a practitioner. They only appear when User is a practitioner is checked. If you uncheck that flag on save, these three fields are cleared — they are not kept hidden in the background. To set a practitioner aside temporarily without losing the data, leave the flag checked.
AGB validation as a hard gate ​
The AGB code has one strict rule: it must be empty or consist of exactly eight digits. A value of, say, seven digits or one containing letters is rejected — both the screen and the server then block saving. This applies both when creating and when filling in practitioner details. Leave the field empty if there is no AGB code (yet); an empty field is valid.
Roles and team as drivers ​
What a user can do and see in Scrivio largely follows from two choices on the detail screen:
- Roles determine the permissions. Each role bundles permissions; the sum of all of a user's roles determines what they may do (see Roles & permissions). Permissions are cumulative — multiple roles stack.
- Team largely determines visibility: team membership governs which clients, appointments, and signals a user gets to see.
In short: roles answer "what may this user do?", team answers "which data does this user see?". Changes to roles and team carry over to nearly every other screen.
Invite user ​
Click Invite in the top right to invite a new staff member. A dialog opens in which you fill in the email address and the role. The user receives an email with an invitation link to activate their own account. This button and action are only available with the users.invite permission.
| Field | Required | Description |
|---|---|---|
| Email address | Yes | The email address the invitation is sent to. |
| Role | Yes | The role the user receives once they accept the invitation. |
After sending, the invitation appears in the list of pending invitations.
Create user ​
Click New user in the top right to create an account directly, without an invitation email. A dialog opens with the user's full details. Creating a user requires the users.create permission.
| Field | Required | Description |
|---|---|---|
| Email address | Yes | The user's email address; must be a valid email address. |
| First name | Yes | The user's first name. |
| Prefix | No | Optional name prefix (for example, "van der"). |
| Last name | Yes | The user's last name. |
| Phone number | No | The user's phone number. |
| Job title | No | The user's role within the organization. |
| AGB code | No | Eight-digit AGB code; only relevant for practitioners. |
| BIG registration | No | BIG registration number; only relevant for practitioners. |
| Account is active | No | On by default; an active account can sign in. |
| User is a practitioner | No | Marks the user as a practitioner. Only then can a profession code be selected. |
| Profession code | No | Visible when User is a practitioner is checked; the NZa profession code. |
The AGB code must be empty or consist of exactly eight digits; otherwise the user cannot be saved.
Search ​
Use the search bar in the top left to quickly find a user. The query filters on name and email address.
| Field | Required | Description |
|---|---|---|
| Search term | No | Part of a name or email address. The list is filtered after searching. |
Sort ​
Click a sortable column header — Name, Email or Status — to sort the list by that column. Click the same header again to reverse the sort order (ascending or descending).
Filter by status ​
Next to the search bar are filter buttons: All, Active and Inactive. Click a button to show only users with that status. The All button shows the total number of users. By default the filter is set to All.
View pending invitations ​
Below the user overview is the Pending invitations section with all sent invitations that have not yet been accepted. For each invitation you see the email address, the assigned role, who sent the invitation, and when it expires. Invitations that expire soon are highlighted. This section is only visible with the users.invite permission.
Revoke invitation ​
Click Revoke on a pending invitation to invalidate it. A confirmation dialog appears; after confirming, the invitation link expires and the invitee can no longer activate the account. To grant the person access after all, send a new invitation.
Activate or deactivate user ​
Open a user's detail screen by clicking the row (/organization/users/:userId). In the Status section, check or uncheck Account is active. A deactivated account can no longer sign in but is kept within the organization. The change is only applied after you save. Editing requires the users.update permission.
Enable practitioner ​
In the Status section, check User is a practitioner to mark the user as a practitioner. Practitioners can be linked to care trajectories and appointments. As soon as you check this option, the practitioner fields (profession code, AGB and BIG) appear. Save to keep the change.
Fill in practitioner details ​
When User is a practitioner is checked, you fill in the related professional details. These fields are needed for correct billing.
| Field | Required | Description |
|---|---|---|
| Profession code | No | The practitioner's NZa profession code (for example, GZ-psycholoog or Psychotherapeut). |
| AGB code | No | The practitioner's eight-digit AGB code. |
| BIG registration | No | The practitioner's BIG registration number. |
When you uncheck the practitioner flag again, these details are cleared on save.
Assign roles ​
In the Roles section on the detail screen, check the roles the user receives. Each role bundles a set of permissions; you can assign multiple roles at once. Uncheck a role to remove it. The change takes effect after you save.
Assign team ​
In the Team section, use the dropdown to choose which team the user is linked to. A user belongs to at most one team; choose No team to remove the user from their team. The link is optional and is saved together with the other changes.
Save ​
Click Save changes at the bottom of the detail screen to save the modified status, practitioner details, roles and team. The button is only active when something has actually changed. Cancel returns you to the overview; if there are unsaved changes, the screen asks for confirmation. Saving requires the users.update permission.