Invite a user and set their access
Create a PTRS login for a new person, give it the roles and site access their job needs, and know exactly what the confirmation message does and does not guarantee.
Before you start
At least one site needs to already exist if you want to grant site access at the same time; the site list comes straight from what your organisation already has. Sites are created from Centers' own Add Site screen. You can only ever grant a role at or below your own level, since the role choices you are offered are already filtered down to that level before you see them. And the email address must not already exist anywhere in PTRS or in the sign-in service, or the save refuses with the address named in the message.
Steps
1. Open the user list
The heading reads User Management. Four filters sit across the top: search, roles, locations and status. Search matches a display name or an email, without regard to case.
The total shown above the table is worked out before a chosen role filter is applied, and the filter itself then runs afterward. With a role selected, the caption and the page count both describe the unfiltered total, and a later page can come back empty even though the rows you can actually see are correct.
2. Select Invite User
The dialog is headed Invite New User and says it will create a new account and send a password setup message.
| Field | Required | Rule PTRS enforces |
|---|---|---|
| First Name | Yes | Not empty, up to 100 characters |
| Last Name | Yes | Not empty, up to 100 characters |
| Yes | A valid address, up to 300 characters | |
| Roles | At least one | Every value must be a role PTRS recognises, and one you are allowed to grant |
| Locations | No | Each one must belong to your own organisation |
The dialog itself refuses to submit if a name, an email or a role is missing.
3. Select Send Invitation
Six things happen, in this order. Every role you chose is checked against the hierarchy first, and a role above your own stops the whole request, naming the role. The email is checked against every existing PTRS account. The sign-in account is created, and if one already exists at that address, the whole request stops there too. Each role is then assigned; a failure here is recorded and the request carries on without that role. A password-setup message is then requested; a failure here is recorded and the request carries on regardless. Finally, the PTRS account record and any site assignments are saved.
This message appears on any successful response, and two of the six steps above are allowed to fail quietly without affecting that outcome.
The email itself is sent by the sign-in service, not by PTRS, using a different setting from the one that governs every other message PTRS sends. Neither of PTRS's own environments configures a mail server for that sign-in service, so whether an email is actually delivered depends on a setting outside PTRS entirely.
Worse, when the email step fails, the record of that failure is written in a shape the new account's own activity screen can never actually match against, so the failure cannot appear on the one screen that would show it.
Confirm outside PTRS that the person actually received the email, and if they did not, set their password directly through the sign-in service instead.
4. Adjust roles afterwards
Open the account from the list. The Roles card shows every current role with a way to remove it, and, underneath, a way to add anything else you are allowed to grant. Both directions are checked against the hierarchy again on the server, so an organisation administrator can never remove a super admin's role, even by attempting the request directly.
A role lives inside the token a person's browser is already holding after they sign in. The change itself is saved right away, and the person's current session keeps using the roles it already has until they sign out and back in.
5. Adjust site access
The Location Access card's Edit control lets you toggle sites and save. Saving replaces the whole set of sites for that account rather than adding to it, checks every site against your own organisation, and takes effect on that person's very next request.
Site access only matters for a site director, a regional director or a staff account. An organisation administrator, a super admin and a read-only account are all given every active site in the organisation regardless of what is recorded here.
What you now have
A sign-in account, a PTRS record carrying your organisation's id, the roles you chose, and any site assignments. That is everything the person needs to sign in.
It is not a staff record. Credentials, background checks, scheduling, ratio counting and the staff directory all depend on a staff record, which this flow never creates. See How a person becomes a PTRS user.
Deactivating and reactivating
Deactivate User does three things at once, and clears that account's remembered access so the change takes hold on their very next request: it disables the sign-in account, marks the PTRS record inactive, and removes every site assignment. You cannot deactivate your own account.
Reactivate User re-enables the sign-in account and marks the PTRS record active again, and does not restore the site assignments. After reactivating someone, set their site access again from scratch.
Common errors
| Message | Cause | Fix |
|---|---|---|
| "You cannot assign the 'X' role, it is above your own role level." | The hierarchy check refused it | Ask a super admin |
| "Role 'X' is not a valid assignable role." | The name is not one PTRS recognises. The OCCL auditor role is the only real-world case | It cannot be assigned. Neither sign-in environment defines it |
| "A user with email '…' already exists." | A PTRS account already has that address | Search for them. They may be deactivated, in which case reactivate rather than re-invite |
| A message saying the email already exists on the sign-in side | The sign-in service has the address and PTRS does not | Resolve it in the sign-in service directly, then re-invite |
| A message saying the account is not synchronised and cannot be changed here | The stored sign-in reference is a placeholder from a development copy of PTRS | Expected on built-in accounts. They cannot be managed here |
| "You cannot deactivate your own account." | The self-check | Ask another administrator |
| No users found matching your filters. on a fresh look | This same message also appears when the request was refused outright | Check your own role first, then your filters |
Related
Checked against PTRS on 7 September 2026.