Overview
Squizify has two core alert systems that run independently.
System | What it does | Triggered by |
External Alerts | Sends SMS/email/WhatsApp notifications to users | Breach time + Notify After + Time Rule |
In-App Alerts | Shows a pop-over modal inside the Squizify app prompting staff to take action | Same settings as External Alerts — Notify After + Time Rule + Dormant |
⚠️ Important: In-app alerts and external alerts share the same settings (Notify After, Time Rules, Dormant) and behave identically for the initial alert. The key difference is in recurring behaviour — in-app recurring alerts ignore Time Rules and Dormant and always fire until the sensor is back in range, while external recurring alerts continue to respect them.
System 1 — External Alerts (SMS / Email / WhatsApp)
How it works
Three things must align for an SMS to send.
Think of them as 3 gates — all must pass.
Gate | Name | What It Controls |
1️⃣ | Sensor Breach | Temperature goes out of range — clock starts immediately |
2️⃣ | Notify After | How long after the breach before SMS is attempted |
3️⃣ | Time Rule | What hours SMS is actually allowed to send |
Gate 1 — Sensor Breach
Temperature goes out of range → breach is logged immediately
The Notify After clock starts from this exact moment
No SMS yet — this is just the starting gun
Example: 05:50 — Temperature hits 7°C → breach detected, clock starts
Gate 2 — Notify After
The system waits X minutes from the breach before attempting to send an SMS. This avoids noise from brief, insignificant breaches.
Logic:
Breach detected → clock starts
Wait X minutes (the Notify After value)
Check — is the breach still active?
✅ Yes → eligible for SMS (proceed to Gate 3)
❌ No → no SMS ever sent
Example : Notify After = 120 minutes
05:50 breach → 07:50 Notify After check
Gate 3 — Time Rule
Restricts when SMS is allowed to go out, regardless of alert status.
Check happens inside allowed window → SMS sends immediately
Check happens outside allowed window → SMS is held until window opens
When window opens → system checks again. Still active? SMS sends. Resolved? Nothing goes out.
Example : Allowed window = 7:00 PM – 7:00 AM
Worked Examples
❌ Scenario 1 — Breach Resolves Before Notify After
Time | Event |
05:50 | Breach detected — clock starts |
06:30 | Temperature returns to normal (40 min later) |
07:50 | Notify After check — breach no longer active ❌ |
— | No SMS sent |
Result: The breach resolved itself before the Notify After check. No SMS ever goes out.
✅ Scenario 2 — All 3 Gates Pass
Time | Event |
05:50 | Breach detected — clock starts |
07:50 | Notify After check (120 min) — breach still active ✅ |
07:50 | Time Rule check — within 7PM–7AM window ✅ |
07:50 | SMS sent 🔔 |
Result: All 3 gates passed. SMS fires.
🕐 Scenario 3 — SMS Held by Time Rule
Time | Event |
02:00 PM | Breach detected — clock starts |
04:00 PM | Notify After check — breach still active ✅ |
04:00 PM | Time Rule check — 4PM is outside 7PM–7AM window ❌ → SMS held |
07:00 PM | Window opens — breach still active ✅ |
07:00 PM | SMS sent 🔔 |
Result: SMS sends 3 hours later than the Notify After check. If the breach had resolved before 7PM, no SMS would ever go out.
🔁 Scenario 4 — Recurring SMS Logic
Once the first SMS sends, recurring SMS fires on a set interval as long as the breach remains active and the time window allows.
Setup: Recurring every 60 minutes
Time | Event |
07:50 | 1st SMS sent |
08:50 | Recurring check — still active ✅, in window ✅ → 2nd SMS 🔔 |
09:50 | Recurring check — still active ✅, in window ✅ → 3rd SMS 🔔 |
10:20 | Breach resolves |
10:50 | Recurring check — breach no longer active ❌ → No SMS |
Result: Recurring SMS keeps firing until the breach resolves or the window closes.
🔁🕐 Scenario 5 — Recurring SMS Hits Time Rule Boundary
Time | Event |
05:50 AM | SMS sent (in window) |
06:50 AM | Recurring check — active ✅, still before 7AM ✅ → SMS sent 🔔 |
07:50 AM | Recurring check — active ✅, but window closed at 7AM ❌ → SMS held |
07:00 PM | Window reopens — still active ✅ → SMS sent 🔔 |
Result: The team won't hear about an ongoing breach during business hours — SMS resumes when the evening window reopens.
External Alert — Recurring Behaviour Summary
Scenario | Behaviour |
Initial alert | Follows Notify After + Time Rule + Dormant |
Recurring alert | Sends only within configured Time Rules |
Time rules (recurring) | Respected — SMS held outside window |
Dormant (recurring) | Respected |
Stop condition | Sensor back in range |
Intent: External alerts target individual people, so they must respect working hours, duty schedules, and right-to-disconnect expectations.
System 2 — In-App Alerts
How it works
In-app alerts use the same settings as External Alerts — Notify After, Time Rules, and Dormant all apply identically. The difference is purely in the output: instead of sending an SMS or email, the system shows a pop-over modal inside the Squizify app prompting staff to take action.
There is no brand-level or profile-level configuration in the standard product, and no concept of High Risk vs Standard sensors — all sensors are treated equally.
What the Pop-Over Looks Like
When a Notify After threshold is reached, a modal appears on screen showing:
"ALERT UNRESOLVED" header with a reminder badge (e.g. "60 Minute Reminder")
Sensor name, temperature range, and exact alert start time
"Action Required" prompt with instructions to take corrective action
Action buttons: Add an action, Cleaning, Maintenance, Other
MUTE button to suppress further pop-overs temporarily
In-App Alert — Behaviour Summary
Scenario | Behaviour |
Initial alert | Follows same Notify After + Time Rules + Dormant as external alerts |
Recurring alert | Always fires while sensor is out of range |
Time rules (recurring) | Ignored — see Key Difference section below |
Dormant (recurring) | Ignored — see Key Difference section below |
Stop condition | Sensor back in range |
Intent: In-app alerts are operational signals on shared devices. Once an issue is known and unresolved, the system must keep notifying staff until it's fixed — regardless of time of day or dormant settings.
⚠️ Key Difference: In-App vs External Recurring Behaviour
The initial alert behaves the same for both systems — it follows Time Rules and Dormant settings. The difference kicks in for recurring alerts:
| In-App Alerts | External Alerts (SMS/Email) |
Initial alert | Follows Time Rules + Dormant | Follows Time Rules + Dormant |
Recurring alert | Always fires while sensor is out of range | Sends only within configured Time Rules |
Time rules (recurring) | Ignored | Respected |
Dormant (recurring) | Ignored | Respected |
Stop condition | Sensor back in range | Sensor back in range |
In short: once in-app alerts start repeating, nothing stops them except the sensor coming back into range. External recurring alerts still respect your time window and dormant schedule.
Push Notifications – How They Work
Push notifications are tied to sensor in-app alerts.
When an in-app alert is enabled and triggered, the push notification is automatically sent at the same time.
Push notification settings are configured together with the in-app alert settings.
There is no separate setting within Squizify to turn push notifications on or off.
These are controlled through the device settings:
Notifications must be allowed for the Squizify app on the device.
If notifications are disabled on the device, push alerts will not appear.
Multiple Devices and Logins
Notifications are linked to the user login and sent to all devices logged in with that user at the time the alert is triggered.
If a user mutes an alert, it is muted for that user account across devices.
Once muted, the alert will no longer appear on the user’s other logged-in devices.
If you have any further questions or need any additional information, please feel free to reach out to our support team and they will be happy to assist further.