Skip to main content

How a person becomes a PTRS user

One member of staff is represented by three separate records, in three separate places, each with its own identifying value. Knowing which is which explains most of the surprises on the administration screens, and explains why an imported staff member cannot sign in at all.

The three records​

RecordLives inWhat it gives the person
A sign-in accountThe sign-in serviceThe ability to authenticate, and the roles PTRS's own rules are written against
A PTRS account recordThe PTRS databaseAn organisation, site assignments, a profile and preferences, and therefore the ability to reach any screen at all
A staff recordThe PTRS databaseA place in the staff directory, credentials, background checks, scheduling and ratio counting

What creates each one​

The sign-in account and the PTRS account record, together, from one save​

Sending an invitation is the only path in the product that creates both, in one save: the sign-in account, then its roles, then a request for a password-setup message, then the PTRS account record carrying the inviter's own organisation, then its site assignments.

The PTRS account record on its own, from a sign-in identity​

A separate save exists that takes a sign-in identity, an email and a display name, and creates or updates a PTRS account record from them. Two things about it matter. It never sets an organisation, because it has nowhere to get one from: it runs before PTRS has resolved any organisation context at all, and nothing about the save itself carries one either. And nothing in the product ever calls it: the one function written for it has no screen and no control anywhere that uses it.

The staff record, from a different part of PTRS entirely​

A staff record is created on the Staff module's own screens, or by the import wizard. Neither of those creates a sign-in account, and neither creates a PTRS account record.

An imported staff member is given a placeholder value where a real sign-in reference belongs, with a note in the underlying save saying plainly that it still needs to be matched up properly. Nothing anywhere in PTRS ever performs that match.

Why a PTRS account record with no organisation is useless​

Almost every request first has to resolve which organisation is making it. That resolution looks up the signed-in account's own PTRS record and reads its organisation. If there is no such record, or the record's organisation is blank, the request is refused outright with a message saying the account is not yet assigned to an organisation and asking the person to contact their administrator.

Every screen in PTRS behaves that way, with a short list of exceptions: signing in itself, a small number of health and reference checks, and the one save that resolves your own account details in the first place, since that is exactly what would otherwise need to already be resolved before it could run.

The bootstrap problem​

Follow those two facts around and they close on themselves.

To use PTRS at all, an account needs a PTRS account record that already has an organisation on it. The only thing in PTRS that ever sets that organisation is the save behind sending an invitation, and it takes the value from the person sending the invitation's own, already-resolved organisation. So only an account that already has a working organisation can ever give one to somebody else. And the organisation itself has no way to be created at all: only a copy of PTRS built for development, and one built for automated testing, can ever create one.

The very first organisation, and its very first administrator, cannot be created through PTRS itself. They have to be put directly into the database, and every later account follows from that one by invitation. That is the single most important thing to know before setting PTRS up for a real organisation, and it is why Getting started reads as an explanation of a sequence rather than a set of steps you can follow all the way to the end.

Sites, and who does not need to be assigned one​

Three roles, an organisation administrator, a super admin, and a read-only account, are given every active site in the organisation automatically, regardless of what is actually recorded for them. Every other role, a site director, a regional director, a staff account, or a guardian, is limited to exactly the sites recorded on their own record.

That is why the site-access section on a person's own record matters a great deal for a site director and means nothing at all for an organisation administrator, and why running an import as an organisation administrator can land the data on any site in the whole organisation rather than the one you meant.

A read-only account is the odd one out here: it is given every site, and it still satisfies none of the settings that actually gate a screen, so it reaches the front door of every part of PTRS and is refused everywhere behind it.

A request can be narrowed to one site​

A request can name a single site directly rather than relying on the sites recorded for the account. PTRS checks that the named site genuinely belongs to the signed-in account's own organisation, and, for anyone outside the three all-site roles above, that the site is actually one of theirs. No screen in PTRS uses this today. It exists for a system talking to PTRS directly rather than through a screen.

Two consequences worth knowing​

An invited account is not a member of staff​

Sending an invitation produces a working login. It does not put the person in the staff directory, does not create a credential record, does not make them schedulable, and does not count them toward a staff-to-child ratio. All of that comes from the staff record, which inviting someone never creates.

The reverse is also true. A staff record created on the Staff screens or by an import produces someone who appears in the directory, in the ratio count and in the credential tracker, and who cannot sign in at all.

Nothing in PTRS joins the two. There is no screen, no automatic check and no import that ever matches a person's sign-in account to their staff record. Setting a person up completely today means doing both halves separately, and knowing that PTRS will never notice if only one of them was done.

The account table has no automatic organisation boundary​

Every other kind of record in PTRS is automatically limited to its own organisation by a single, shared rule applied everywhere at once. The table holding PTRS account records is deliberately excluded from that rule, because one account can genuinely span more than one site through its own assignments, and the shared rule was not built to express that.

Every user-management save compensates for this by checking the organisation itself, by hand, every time. One read of a single account by its own id does not: it can return any account in the whole installed copy of PTRS, including a home address and a date of birth, with no organisation check standing in front of it at all. Nothing in the product calls it today, and the values it would need are long, unguessable identifiers that no other screen ever hands out, but the check itself is simply missing rather than passed.

Accounts built into a development copy of PTRS, and why you cannot edit them​

A development copy of PTRS is given account records whose sign-in reference is a readable placeholder rather than a genuine one. Every save on a person's own detail screen checks that value first, and refuses to continue if it does not look like a real one, saying plainly that the account is not matched up with the sign-in service and cannot be changed from that screen. That refusal is deliberate: attempting the matching change against a placeholder would otherwise come back as a confusing, unrelated-looking failure instead of a clear explanation.

Checked against PTRS on 7 September 2026.