Getting started

PTRS has no setup wizard. Nobody is walked through opening a new organisation; there is no checklist screen and no first look at an empty club that tells you what to do next. This page is the order the six steps have to happen in, written out because nothing inside PTRS itself will tell you.

Three of the six cannot be done through PTRS at all. They are marked below, with the reason, so you can plan around them instead of running into them partway through.

The sequence at a glance

#	Step	Can you do it in PTRS?
1	Open the organisation	No. Someone has to create the record directly
2	Create the first administrator	No. The first account closes on itself
3	Create the sites	Yes. Centers, Add Site
4	Load your existing records	Yes, though PTRS keeps 41 of the 64 fields it offers
5	Create staff accounts	Half. Two separate records, and nothing connects them
6	Turn on the Parent Portal for families	No. Nothing does this today

Steps 3 through 5 have to happen in that order: sites have to exist before a file of records can be loaded, and staff have to exist at a site before attendance, meal counts or incidents can be loaded into it.

---

Step 1: Open the organisation

Nothing in PTRS opens a new organisation

No screen and no save anywhere in the product creates one. The only places an organisation record is ever written are the development copy PTRS builds for itself, and the checks PTRS runs on itself before a change ships. Opening a real one today means someone writing the record in directly.

The record itself needs a name, a state, and a license number. It can also carry a short web address, a logo, and a handful of settings, all optional. An organisation is marked active from the moment it is created, and every account is refused the moment its own organisation is turned off.

Delaware's two-letter state code is what belongs here; a longer state name will not fit one of the places it is checked against later, on a site's own record.

Everything else in PTRS depends on this record existing first. Every record anywhere in the product, a child, a staff member, an attendance mark, points back at one organisation, and every screen that lists or searches anything only ever shows records from the organisation the signed-in account belongs to.

---

Step 2: Create the first administrator

The first administrator cannot be created from inside PTRS

This one closes on itself. Reaching any screen in PTRS requires an account already tied to an organisation; an account with no organisation is turned away everywhere, shown a message saying so.

The only place in PTRS that ever assigns an organisation to an account is the invitation an administrator sends to somebody else, and that action takes the organisation from the administrator's own account. So the very first administrator cannot be created by inviting them, because there is nobody with an organisation yet to send the invitation.

There is a separate save that registers a new sign-in identity, and it never assigns an organisation either, so it cannot close the loop by itself. Nothing in the product calls it today in any case.

The full reasoning is at How a person becomes a PTRS user.

Two things have to exist before the first person can sign in and work.

1. A sign-in account on the organisation-wide sign-in service, holding an organisation administrator or a super admin role. The sign-in service knows seven roles in total: super admin, organisation administrator, regional director, site director, staff, parent, and read-only.
2. A PTRS account record whose stored sign-in reference matches that sign-in account exactly, and whose organisation is the record from step 1.

Both halves have to agree. If the PTRS record exists but its stored sign-in reference does not match, reading your own account details comes back empty, no screen ever finds an organisation to show you, and every screen renders its ordinary empty state rather than an error. That is exactly what happens to the guardian account built into PTRS's own development copy, and it is written up in full at How your account is linked to your child.

Setting this up also depends on configuration outside PTRS itself. The connection settings that let PTRS talk to the sign-in service's own management side have to be filled in, or every user-management screen fails before it even starts. The account behind that connection also needs permission, on the sign-in service's own side, to manage users and read the organisation's role list.

Checkpoint

Signing in with that account and opening any screen loads normally, with no message about a missing organisation. Reading your own account details shows the organisation you expect.

---

Step 3: Create the sites

This step works. Go to Centers, then Add Site. It is written up in full, including the fields the form collects and quietly discards, at Add a site.

Who can do this

• Site director
• Organisation admin
• Super admin

The Add Site button is shown to a staff member and a regional director too. Both can open the form and both are turned away on submit with a permission message.

There is also a second, screen-free way to create the same kind of record, reachable only by sending a save directly rather than through any button in the product. It fills a site's city and postal code with nothing and its capacity with zero, and copies the state straight from the organisation. Nothing in PTRS's own screens ever uses it; Add Site is the only way most people will ever create one.

Do this before step 4. The very first save in the import wizard reads the first site your own account can reach, and fails outright with no useful message if you can reach none. Loading records into an organisation with no sites yet does not work.

Checkpoint

Centers lists your sites, and that same list is what fills every site picker on the user and import screens afterward.

---

Step 4: Load your existing records

This step works, inside limits worth planning around. The wizard is under Administration, Import a file, and is written up in full at Import a file of records.

Who can do this

• Site director
• Organisation admin
• Super admin

PTRS's own rule for this action admits a site director too. The screen checks a narrower rule and turns a site director away with a permission message, so run this step as an organisation administrator instead.

Six kinds of record can be loaded this way: children, staff, programs, attendance, meal counts and incidents. The wizard offers 64 fields in total, and only 41 of them are ever actually written, and the 23 that are quietly discarded fall into two clean groups:

• Every guardian and emergency-contact column on a file of children. No guardian record is ever created by this wizard.
• Every certification and background-check column on a file of staff. Neither record type is ever created by this wizard.

Both groups have to be filled in afterward, by hand, on the Members and Staff screens. The full field-by-field account of what survives and what does not is at What an import writes.

The order within this step matters too.

1. Staff first. Attendance, meal-count and incident records each need an active staff member already at the site to record them against, and every row fails with a message saying so if there is none.
2. Children next. Attendance records look a child up by first and last name alone, and fail the row if no match is found.
3. Programs, attendance, meal counts and incidents after that.

Two things are worth knowing before you commit to a load. The site you choose on the wizard's first screen is never actually sent along, and the choice you make later about duplicate records was already decided back at the moment you uploaded the file. Both are explained in full on the how-to page.

Checkpoint

The results screen shows four counts: Created, Merged, Failed and Skipped. These are genuine counts, worked out row by row as the load runs, not a fixed display. Revert Import is available on that same screen and nowhere else, so review the results before you move on to another screen.

---

Step 5: Create the staff accounts

This step half works, and the missing half is the connection between its two pieces.

A staff member needs two separate records, and PTRS creates them through two paths that never meet:

To give them	Do this	What it creates
A way to sign in	Administration, Invite a user	A sign-in account, its roles, a password-setup message, and a PTRS account record carrying your organisation
A staff record	Staff, its own create screen, or a staff file load	A record with credentials, a background check, a place in the schedule and in the ratio count

Nothing in PTRS connects the two. There is no step anywhere that matches a signed-in account to a staff record for the same person. A staff member brought in through a file load is given a placeholder sign-in reference that plainly says it still needs to be connected, and nothing ever performs that connection.

So for each person, decide what they actually need and do both halves on purpose:

• Somebody who only needs to sign in: invite them.
• Somebody who only needs to show up in the staff directory, the ratio count, or credential tracking: create or load a staff record for them.
• Somebody who needs both: do both, and use the same email address on each so a person looking later can tell the two records belong to the same staff member.

On site access: a super admin, an organisation administrator and a read-only account can already see every active site, regardless of what is assigned to them. For a site director, a regional director or a staff account, the Location Access card on their account record is what decides, and saving it replaces the whole list rather than adding to it.

The invitation message comes from the sign-in service, not from PTRS

Sending an invitation asks the sign-in service to deliver a password-setup message, and treats a failure to do so as something to quietly record rather than something to report back. Neither of PTRS's own environments has a mail server configured for that service. Confirm outside PTRS that each invited person actually received their message; if they did not, set their password directly through the sign-in service instead.

Checkpoint

Each invited person can sign in and reaches a working screen rather than a message about a missing organisation. Each staff record shows up in the staff directory.

---

Step 6: Turn on the Parent Portal for families

Nothing turns the Parent Portal on for a family

This is the one gap an administrator following every step above will still run into at the end.

The one piece of information PTRS checks to show a signed-in parent their own child has exactly one place it is ever written, the development copy PTRS builds for itself, and no screen, no save and no file load anywhere in the product ever sets it for a real family. Loading a file of children discards the guardian columns entirely, so it does not even create the guardian records a future connection could point at.

You can create an account holding the parent role; it is one of the sign-in service's seven roles, so it appears as a choice on the invitation screen and an invitation using it succeeds. That account will sign in and reach its own dashboard without any error.

And every screen it reaches will be empty. Reading that account's own details never returns a linked child, every screen built for a parent quietly has nothing to ask for, and no request for anything useful is ever actually sent. A guardian whose account was never linked and a guardian whose child genuinely had a quiet week see the exact same screen.

The full evidence is at How your account is linked to your child.

Plan around it. Until a connection exists, treat the Parent Portal as not ready for families: do not invite guardians into it, and do not tell families that alerts or messages will reach them there. The Parent Portal is also not an emergency channel in any case; nothing in PTRS today ever creates an emergency alert.

---

What runs on its own once you are live

Nothing described on this page runs on a schedule. Across PTRS as a whole, a dozen background jobs run on a timer, alongside two more processes that run continuously. What each one selects and writes is covered on the pages for the module that owns it: Staff, Centers, Compliance, Attendance, Members and Health & Safety.

Two things are worth knowing on day one, because they change what you should tell your own staff:

• PTRS has never sent a notification of any kind, through any channel. Its message-sending is recorded to a log only, in every copy of PTRS covered by this documentation. Any screen text saying that somebody was emailed, texted or alerted is fixed wording, not a report of something that happened. See Notifications.
• The menu applies no check of its own. Every signed-in account sees every menu item, and only finds out on opening a screen whether that screen actually works for them.

Where to go next

• Invite a user and set their access
• Import a file of records
• What an import writes
• How a person becomes a PTRS user
• Add a site
• Roles and what each can reach