Open a new organisation

Turning an empty installation of PTRS into a working one takes six steps across five different parts of the product. Three of the six cannot actually be performed through PTRS at all, and the whole sequence exists nowhere inside PTRS as a guided path: there is no setup wizard, no checklist screen, and no first-run experience of any kind.

The full treatment, step by step with the screen behind each one, is Getting started. That page is the depth; this one is the flow: the order, the hard dependencies between steps, and the one thing an implementer most needs and cannot get from any single page on its own, which of the other six flows actually work once you are actually live.

The sequence at a glance

#	Step	Part of PTRS	Can PTRS do it?
1	Create the organisation	Administration	No. Written directly, with nothing behind it
2	Create the first administrator	Administration	No. Written directly on both sides
3	Create the sites	Centers	Yes. See Add a site
4	Load the existing data	Administration	Yes, with 23 of 64 offered fields discarded. See Import a file of records
5	Create the staff accounts	Administration, Staff	Half. Two separate records per person, and nothing connects them
6	Enable families for the Parent Portal	Parent Portal	No. Nothing does this today

Each row's own reasoning, and the evidence behind every "No," is on Getting started.

The hard ordering

Three dependencies here are real constraints rather than just good practice, and getting them wrong produces an actual failure rather than a warning.

Sites before loading data. The very first save the import wizard makes reads your own first assigned site, and fails outright when that list is empty, so an import into an organisation with no sites at all returns an unexpected failure.

Staff before attendance, meal counts and incidents. Each of those three kinds of import picks an active staff member at the site to record against, and fails every single row with a message saying no active staff member was found, if there is none.

Members before attendance. Loading attendance looks a child up by first and last name, and fails the row outright if it cannot find one.

So within step 4, the actual order is: staff, then members, then programs, attendance, meal counts and incidents.

The two connections an implementer has to make by hand

These are the real cost of this whole flow, and neither one is visible from inside any single part of PTRS on its own.

A staff member and a person who can sign in are two different records

Someone who needs to sign in needs an invitation, which creates both a sign-in account and a PTRS account record. Someone who needs to appear in the staff directory, the ratio count or the credential tracker needs a staff record instead, created either directly or through a staff import.

Nothing in PTRS connects the two automatically. There is no step anywhere that matches one to the other, and a staff member brought in through an import is given a placeholder identifier, with a note saying it still needs to be connected, a connection that does not actually exist anywhere in the product.

Decide, for each person, exactly what they actually need, do both halves of this on purpose, and use the same email address on both so a person looking later can tell the two records belong to the same individual. See how a person becomes a PTRS user and invite a user and set their access.

Every flow on this whole site that involves staff is affected by this one gap. It is exactly why keep a credential current opens by saying plainly that a staff member is not the same as a person who can sign in.

The import discards guardians and credentials

The import wizard offers 64 fields and actually writes 41 of them. The 23 it drops fall into two clean, coherent groups, not a scattered list.

Every guardian and emergency-contact column on a load of children. No guardian record is ever created by any import, of any kind.

Every credential and background-check column on a load of staff. Neither a credential record nor a background-check record is ever created by any import either.

Both of these groups have to be entered afterward, by hand, on the Members and Staff screens. The full, field-by-field list is at what an import writes.

If you hold paper membership forms, scanning beats importing

Quick Scan genuinely does create a guardian record, the link between guardian and child, and an emergency contact, straight from a photographed form, all in one save, which is exactly what loading a spreadsheet will never do. See scan a paper application.

What works on day one

This is the part that belongs on a flow page rather than a setup page: once steps 3 through 5 are actually done, here is what a club can genuinely run.

Flow	On day one
Enrol a child	Yes. Both checks work; the CACFP tier is typed in by hand
Run a service day	Yes for check-in, meal counts and check-out. No for any actual ratio reading
Report an incident	Yes, as a record. Nobody is actually notified
Keep a credential current	Only by opening the screens yourself. Nothing is ever delivered
Close a month	The statistical report and funder reports, yes; the CACFP claim cannot actually be created
Scan a paper application	Only if the outside AI service's own access key is actually set. It is blank in the production template

Two facts, true across the whole product, change what you should actually tell your own staff before they start.

PTRS has never created a notification of any kind, through any code path, and its own message-sending is recorded to a log only, on every installation covered by this documentation. Any screen text saying somebody was emailed, texted or alerted is fixed wording. See Notifications.

The menu applies no check of its own at all. Every signed-in account sees every menu entry, and only finds out on opening a screen whether it actually works for them. See Roles and what each can reach.

What runs on its own once you are live

Twelve recurring background jobs and two continuously running processes are built into PTRS. Their own schedules, all worked out in a single fixed time zone that puts five of them in the small hours of a Delaware morning, and what each one actually writes, are on the pages for the part of PTRS that owns them: Staff, Centers and Attendance.

Nothing a scheduled job does is ever written to the audit trail; that trail only records changes made by a signed-in person through PTRS itself. Do not plan to verify a job's own work by reading it. See the audit hash chain.

Two roles have no workable setup

A read-only account satisfies no rule anywhere in PTRS, and an OCCL auditor is a role PTRS cannot actually assign at all, since neither of its own sign-in environments defines it. Do not plan an installation around either one. See Roles and what each can reach.

Step 6: the one thing you will not have

There is no step that turns the Parent Portal on for a family

The one piece of information PTRS checks to show a signed-in parent their own child has exactly one place it is ever written anywhere in the whole product: a development copy's own starter data. No screen, no save, no registration process and no importer ever sets it, and loading a file of children does not even create the guardian records a future connection could point at.

An account holding the guardian role will still sign in and reach its own dashboard, and every screen it reaches will be empty, because 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.

Plan around this: 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 full evidence is at how your account is linked to your child.

Related

• Getting started, the full six steps with the evidence behind each one
• Administration overview, Centers overview
• Add a site, Import a file of records
• Change your own password