What notifications PTRS can and cannot send

Read Notifications first. Nothing on this page produces a message that reaches a person today, because no notification has ever been created. This page describes what is built so that you know what the screens are showing you, and what would be needed before any of it could work.

Who can open the notification screens

Everyone who is signed in, including OCCL auditors and read-only accounts. These screens are the only part of PTRS apart from signing in that does not check which organisation you belong to. Each screen shows only notifications addressed to your own account, and since none is ever addressed to anyone, each shows nothing.

There is a second problem behind that. The name PTRS would write on a notification and the name it uses to recognise you when you sign in come from two different places and would not match. So even a notification addressed to you would not appear for you.

The four things the screens can do

What	What it shows or does
List your notifications	Twenty at a time, newest first. There is no upper limit on how many you can ask for at once.
Count your unread notifications	A number. Today it is 0, accurately.
Mark one as read	Records the time you read it. Marking one that is already read does nothing.
Mark all as read	Marks every unread one and writes a single audit trail entry saying how many. If there were none, nothing is written.

The list is the one the Notification Center page and the bell cannot understand, which is why the page shows "Something went wrong" and the bell shows "No notifications". The unread count is understood correctly, which is why the badge on the bell behaves.

Marking a notification as read overwrites its status, so a notification that failed to send and was then marked read shows as read with the failure reason still attached.

Delivery routes

Route	Built?	What it does
In-app	Yes	Sends a message to the guardian's open parent portal screen
Email	Yes	Sends through a mail server, or writes a log line if there is none
Text message	No	Nothing exists
Push to a phone	No	Nothing exists

When a notification is routed to a route that does not exist, it is recorded straight away as failed with the reason "No channel provider for" and the route name. It is kept, not discarded, so a switched-on text message route would leave a permanent trail of failures rather than silently dropping messages.

What in-app actually reaches

Nothing. The route addresses the guardian's screen by a name written one way, and the parent portal registers screens under the name written another way. They never match. The message name is also one 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.

What email actually reaches

In order:

1. If the notification has no email address, the route logs a warning and reports failure.
2. If PTRS has not been given a mail server, the route writes "SMTP not configured, email notification to" the address "logged only" in the log, and reports success.
3. Otherwise it sends the email. If the send fails, it reports failure.

No version of PTRS that can be installed today has been given a mail server, so step 2 is what runs. Before any email can leave, whoever looks after PTRS has to give it a mail server address and, if the server requires it, a sign-in. PTRS's sending address starts as noreply@ptrs.bgcde.org. The same settings serve guardian email and staff email.

Staff email is a separate path

Email to staff about expiring credentials, expiring training, background check results, overdue onboarding and cleared onboarding does not go through Notifications at all and creates no notification record. It goes through a second path with the same mail server setting. With no mail server, that path writes one line in the log per email and stops. Five scheduled tasks and one event send staff email this way, and none of them sends mail today.

The dispatcher

If something did ask PTRS to notify a guardian, this is what would happen, in order:

1. Find the guardian. If there is no such guardian, stop silently, with no record and no log line.
2. If it is the guardian's quiet hours and this is not an emergency alert, log it and stop. Nothing is stored, so a suppressed notification leaves no trace.
3. If the guardian's language is not English, ask the AI pipeline to translate the message. If that fails for any reason, keep the English.
4. Send in-app, always.
5. If the guardian's preferred contact method is something other than the app, send again that way.

So a guardian who prefers email gets two notifications for one event, one in-app and one by email. When PTRS is asked to notify every guardian at a site, a guardian with three children enrolled gets one notification, marked against whichever child PTRS came to first.

Guardian's preferred contact method	Route used
Email	Email
Text message	Text message, which does not exist
Phone	Text message, which does not exist
App	In-app

A guardian who asked to be telephoned would receive a text message if text messages existed. There is no voice route.

Quiet hours

Quiet hours come from the guardian's record. If none are set, or the start or end is missing, or they cannot be read as times, there are no quiet hours. If the start is before the end, the guardian is quiet between them. If the start is after the end, the window runs overnight.

The comparison uses universal time (UTC), not Delaware time. A guardian who set quiet hours of 10 pm to 6 am expecting Delaware time would get a window of roughly 6 pm to 2 am local in summer.

No screen in PTRS lets a guardian set quiet hours.

The two background workers

Both start with PTRS and cannot be switched off or adjusted.

Emergency alert escalation

Every 5 minutes, across every organisation, it finds emergency alerts that are not resolved and were sent more than 30 minutes ago. For each guardian who has not acknowledged, it re-sends with the subject "URGENT: Emergency Alert Re-send" and the message prefixed "[ESCALATION]". Because it is an emergency alert, quiet hours are skipped, which is correct.

There is no limit. The same alert is re-sent every 5 minutes, forever, until it is resolved or every guardian has acknowledged. The re-sent notification is marked against no child.

What it achieves today: nothing. No emergency alert has ever been created, and the only thing that creates an acknowledgement record marks it acknowledged in the same moment, so there is never anyone to escalate to.

Notification retry

Every 10 minutes, across every organisation, it finds notifications that failed and have been tried fewer than 3 times. For each one it finds the route, rebuilds the message from the guardian, the child, the subject and the text, and tries again.

Two things follow. The rebuilt message has no email address, and the email route's first check is for one, so an email can never be retried successfully. And the retry count goes up by two each time, so a notification allowed 3 tries is abandoned after 2 rounds, about 20 minutes.

What a notification record holds

Field	Note
Organisation	Taken from the guardian
Guardian	Set on every notification the dispatcher writes
Child	Set by the dispatcher; blank on an escalation re-send
Staff recipient	Never set by anything
Kind	One of the eight kinds below
Route	In-app, email, text message or push
Status	Pending, sent, delivered, read or failed. Delivered is never set.
Title	Up to 200 characters. The list shows this as the heading, and the dispatcher never fills it in, so it is always blank.
Subject	Up to 200 characters. The dispatcher fills this in, and no screen shows it.
Message	Up to 5,000 characters
Translated message	Never filled in. A translation replaces the message instead.
Sent at, delivered at, read at	Delivered at is never set
Failure reason	Up to 2,000 characters
Retry count
What it is about	The kind of record and which one

A guardian who has notifications cannot be deleted.

Kinds of notification

Check-in, check-out, incident alert, emergency alert, authorisation request, message received, absent alert, weekly summary. Only emergency alert is ever asked for by anything. The other seven name events that nothing in PTRS sends a notification for.

Guardian contact methods

Email, text message, phone, app.

Guardian languages

English, Spanish, Haitian Creole.

Registering a guardian's phone

The parent portal can register a guardian's phone for push notifications.

PTRS needs	Required	What PTRS accepts
The guardian	Yes	Must be a guardian in your organisation, else "Guardian not found."
The kind of phone	Yes	Up to 50 characters. "Platform is required."
The push token	Yes	Up to 500 characters, and only one registration per token. "Push token is required."

Registering the same token again updates the existing registration rather than adding a second. The dispatcher looks up the guardian's newest active registration and attaches it to the message, and no route reads it, because no push route exists.

Related

• Notifications, why none of this delivers anything
• Who learns that an incident happened
• Notifications troubleshooting