Flows

A module is how PTRS is built. A flow is how the work actually happens. A child gets hurt, and what follows crosses four different parts of PTRS and two separate deadlines.

A flow page links pages that already exist. It adds no new claims of its own, because a step that is not already documented on its own module page is a step nobody has actually checked against PTRS. What a flow page adds is the one thing no single module page can show on its own: what carries over from one step to the next, and exactly where that chain stops.

The seven flows

Flow	Crosses	What it is for
Enrol a child	Members, Programs, CACFP	A new child gets a membership, a program place and a meal eligibility record
Run a service day	Attendance, Compliance, CACFP	The day a club runs every single day it opens
Report an incident	Incidents, Notifications, Compliance	A child is hurt, and OCCL has to be told
Keep a credential current	Staff, Compliance, Notifications	A certificate is approaching its expiry
Close a month	CACFP, Analytics, Funders	The CACFP claim, the funder reports and the monthly statistical report
Scan a paper application	Members	A photographed form becomes a child's own record
Open a new organisation	Administration, Centers, Staff	An empty installation of PTRS becomes a working one

What the flows have in common

Reading all seven together turns up four things that show up in most of them, worth knowing before you meet any one flow for the first time.

Nobody is actually notified, in any of the seven. PTRS has never created a notification of any kind, by any means; its message-sending is recorded to a log only, on every installation covered by this documentation; and the one part of PTRS that would actually send a notification is never reached by anything that could call it. Wherever a flow reaches a step where somebody outside the building needs to be told, that step is yours. See Notifications.

The records themselves are more reliable than the screens that summarise them. Attendance records, incident timelines, OCCL status histories, meal counts, credential records and the audit trail are all written reliably. Several of the screens meant to summarise them read from a table nothing ever writes to, or apply a filter that never actually matches anything, and still show a confident figure regardless. Each flow states plainly which of its own numbers are real and which are not.

A staff member and a person who can sign in are two different records. One lives in the personnel file; the other is an account with a password. Nothing in PTRS connects the two automatically, so a person can have either one without the other. See How a person becomes a PTRS user.

A scheduled background job leaves no trace on the audit trail. Twelve such jobs run regularly, and the audit trail only records changes made by a signed-in person through PTRS itself. Do not expect to verify a background job's own work by reading that trail. See The audit hash chain.

What is not a flow

The AI Assistant is not a step in any flow here. It keeps no memory between messages and cannot carry anything from one question into the next, so it cannot take part in a sequence of steps. What it actually is, what it can be trusted to say, and what happens to a child's own information when you ask it something, are covered on AI Assistant and How PII is protected in the AI pipeline.

Where else to enter

Flows are one of three ways into this documentation, and none of the three matters more than the others.

Modules is how PTRS is actually built. Start here to weigh up one part of the product on its own.

Roles is what one person can actually reach.

Flows, this page, is for when you know the work you are trying to do but not yet which screens it touches.

All three lead into the very same pages underneath.