Notifications

Carla Reyes would like a text when Maya arrives at the club. Tom Bradley would like an email when an incident is filed at Claymont while he is away. Neither can have it. PTRS has never sent a notification to anyone, by any route, and cannot today.

Read this before anything else on this page

No email, no text message, no push notification, no in-app message and no entry under the bell has ever been sent by PTRS. Every screen in PTRS that says something was sent is showing fixed words.

The rest of this page describes what has been built, so that whoever picks the work up knows what is already there. It is not a description of anything that works.

Who uses it

Nobody, today.

The notification screens are open to every signed-in account, including OCCL auditors and read-only accounts, which can open almost nothing else in PTRS. Nothing checks which organisation a notification belongs to, because no notification exists to check.

What PTRS does for you

Nothing that leaves PTRS.

The one thing that does work is the live update to open screens. When someone with PTRS open at your site sees a child appear in the arrivals feed the moment they are checked in, that is PTRS updating an open screen. It is the only live signal in PTRS, and it reaches nobody who is not already looking.

From the regulation The two duties that make this more than a convenience are both timed. A Delaware licensing report has a deadline from the moment an incident qualifies, and a guardian has to be told about an injury the same day. That is DELACARE, enforced by OCCL. PTRS stores the deadline as a number of hours and does not store the regulation.

What stays your job

Everything.

• Tell guardians yourself, by phone, text or in person, and write down that you did.
• Tell directors yourself.
• Keep your own deadline reminders. See Who learns that an incident happened.
• Do not tell a family that PTRS notified them. It did not.

The risk is not that notifications are missing. It is that PTRS says they happened. The incident wizard's confirmation list, the ratio monitor's alert bell and the check-out confirmation all say a named person was told. In a licensing dispute or a liability claim, a screen saying "Regional Director notified via email" when nothing was sent is worse than a screen that says nothing.

What has been built

Whether or not it runs:

• A dispatcher that would find the guardian, respect quiet hours, translate for a guardian whose language is Spanish or Haitian Creole, always send an in-app message, and also send by the guardian's preferred contact method when that is different.
• Two delivery routes, in-app and email. No text message route and no push route exist.
• A quiet-hours rule, read from the guardian's record, that handles overnight windows and is skipped for emergency alerts.
• Delivery tracking: pending, sent, delivered, read, or failed with a reason and a retry count.
• A retry worker that runs every 10 minutes and gives up after 3 tries.
• An escalation worker that runs every 5 minutes for emergency alerts not acknowledged after 30 minutes.
• Device registration for guardians' phones, with one active registration used.
• A Notification Center screen and a bell in the header, both reading the same records.

What runs on its own

Two workers start with PTRS and run for as long as it does. Neither can be switched off.

Worker	How often	What it does	What it achieves today
Emergency alert escalation	Every 5 minutes	Finds unresolved emergency alerts sent more than 30 minutes ago and re-sends to every guardian who has not acknowledged	Nothing. No emergency alert has ever been created.
Notification retry	Every 10 minutes	Finds failed notifications with fewer than 3 tries and sends them again	Nothing. There are no notifications.

Nothing in Notifications runs on a longer schedule. The scheduled tasks that do exist in PTRS belong to other parts of it, and none of them tells a person anything. See the 15-minute ratio note for one example.

What it connects to

Part of PTRS	How
Parent Portal	Owns emergency alerts, acknowledgements and phone registrations, and the live channel the in-app route aims at
AI	The dispatcher would ask the AI pipeline to translate a message for a guardian whose language is not English
Members	The dispatcher can walk every active child at a site and message each one's main guardian. Nothing asks it to.
Identity	The Enable Notifications switch on the profile screen saves a preference that nothing reads
Incidents	Not connected. See Who learns that an incident happened
Attendance	Not connected
Compliance	Not connected

Not yet available

This section is the whole of Notifications.

No notification has ever been created, by any route

Only one part of PTRS can create a notification record, the dispatcher, and only one thing ever asks it to: the emergency alert escalation. That escalation looks for emergency alerts more than 30 minutes old that a guardian has not acknowledged. Two facts make that impossible. Nothing in PTRS creates an emergency alert. And the only thing that creates an acknowledgement record marks it acknowledged in the same moment, so an unacknowledged one cannot exist. Everything below follows from this.

The Notification Center page does not open

Opening Notifications from the menu shows "Something went wrong" and a technical error where an explanation should be. Try Again shows it again. This happens for every role, including super admins. It is not a permission problem: the page asks PTRS for the list and cannot understand the answer it gets back.

The bell in the header always reads 'No notifications'

The bell asks for the same list and, unable to understand the answer, shows nothing. It would show nothing even if notifications existed. The unread count badge on the bell reads a different figure that it does understand, and that figure is 0, accurately, because there are no notifications. Mark all read and clicking an entry both work and have nothing to act on.

There is no text message route and no push route

PTRS knows four ways to deliver: in-app, email, text message and push. Only in-app and email are built. A guardian whose preferred contact method is text message or phone would be routed to the text message route, which does not exist, and the notification would be recorded as failed with the reason "No channel provider for SMS". Guardians' phones can still be registered for push, and PTRS looks up the registration, and nothing reads it. A registered phone receives nothing.

Email goes to a log, not to a person, in every version of PTRS

PTRS has to be given the address of a mail server before any email can leave. No version of PTRS that can be installed today has one. Without it, every email PTRS tries to send, to staff or to guardians, becomes a line in PTRS's own log beginning "Would send to". Five scheduled tasks send staff email this way, about expiring credentials, background checks, training, onboarding and licences. All of it is log lines.

The guardian email route goes one step further: with no mail server it reports success, and the notification is recorded as sent with a time. A notification recorded as sent is therefore not evidence that anything was sent.

The in-app route sends to a room nobody is in

The in-app route addresses each guardian by a name written one way, and the parent portal registers guardians under the same name written another way, with a different separator. The two never match. The message it sends also has a name the parent portal does not listen for. Sending to nobody is not an error, so the route reports success and the notification is recorded as sent.

The retry worker cannot succeed on an email

When the retry worker rebuilds a failed notification to try again, it leaves out the email address. The email route's first check is for an address, so every retry of an email fails, whatever the original problem was. The retry count also goes up by two each time, so a notification allowed 3 tries is abandoned after 2 rounds, about 20 minutes, not 30.

Notification preferences are saved and read by nothing

The Notifications card on the profile screen offers one switch, Enable Notifications, described as "Receive alerts for incidents, compliance, credentials, and attendance". Saving it stores the same yes or no against all four categories. Nothing reads them, because nothing sends anything. The four categories cannot be controlled separately, and the switch has no effect. Guardian quiet hours are read by the dispatcher, and no screen in PTRS lets a guardian set them.

The Staff page has a second, unrelated bell

The Staff page has its own bell with its own unread badge and its own button to mark everything read. It is not connected to Notifications. It shows up to 50 live events from the compliance screens, about credentials, ratios, background checks and onboarding, while the page is open. Everything in it is lost on refresh, on moving to another page, and in a second browser tab. It is a live ticker, not an inbox, and nothing on the page says so.

Where these are recorded

These are defects in PTRS, not in this page. They are written up for the PTRS team in the notifications findings document. This guide describes PTRS as it behaves today.

Where to go next

There are no step-by-step pages for Notifications, and that is the honest answer. Every task you could try, opening the Notification Center, reading the bell, marking something read, choosing what to be notified about, either fails or acts on nothing.

Look something up: What notifications PTRS can and cannot send.

Understand why: Who learns that an incident happened.

When something goes wrong: Notifications troubleshooting.