Notifications & Integration
Helix assumes the people it schedules are not sitting at a screen. A standby engineer being called out, a crew being offered a job, a controller who needs to know a channel went quiet — each of these is a conversation, not a broadcast. The notification framework makes that conversation first-class: Helix raises the message on the channel your operation already uses, and the reply comes back through the same door as every in-app response — a WhatsApp button-tap accepts a callout exactly as a tap in the Engineer App would, updating the roster, the plan and the pay record in one motion.
The model
Section titled “The model”Three ideas make the framework flexible without making it fragile:
- The domain decides when, the toolkit owns how. Notifications hang off the same state-change hooks that drive the rest of Helix’s automation — a stop entering the CALL state, a call being stood down, a shift boundary passing. Your domain configuration names the moment; the toolkit handles queueing, delivery, retries and replies.
- Every answer converges on one path. Whether a callout is accepted in the app, by a dispatcher, by your own host system, or by an SMS reply, the same update flows through the same functional helper. Whoever answers first wins; every other channel finds the work already done and stands down quietly. There is no second state machine to drift.
- A dead channel is never silent. Delivery that exhausts its retries raises an action in the dispatcher’s queue — “notification undeliverable, contact manually” — so the manual workaround is built into the process, not bolted on.
Simulation is respected throughout: a replayed scenario never sends — notifications are recorded and visible, but no phone rings for a world that isn’t real.
Channels
Section titled “Channels”Helix ships the framework and the vendor-free channels in core; vendor channels plug in as small client adapters, with credentials staying in your environment — never in Helix.
| Channel | Direction | Provided as | Notes |
|---|---|---|---|
| two-way | client adapter (first-class) | Interactive reply buttons map directly onto the decision — Accept / Refuse as buttons, not typed text. Meta’s Cloud API is plain HTTP; no SDK needed. | |
| SMS | two-way | client adapter (first-class) | The classic callout channel: any handset, no app, no smartphone. Free-text replies (“YES”) are matched to the outstanding call. |
| Web push | two-way | core (planned) | The Engineer App is a browser app, so push needs no vendor at all — the notification opens straight into the app’s own response screen. |
| Webhook | two-way | core | The universal integration point: Helix POSTs the event to your system; your system answers on a single-use reply URL. This is how an existing host keeps running its own callout while Helix runs everything else. |
| Email (SMTP) | two-way | core | Reachable everywhere, weak urgency — best for summaries, stand-downs and audit copies. Replies via signed links. |
| Voice call (IVR) | two-way | client adapter | ”Press 1 to accept” — the strongest wake-someone channel, and the natural escalation step: unanswered push → SMS → voice is a policy over channels, not new machinery. |
| Slack / Teams / Telegram | two-way | client adapter | Better suited to the dispatcher side — refusals, stand-downs, delivery failures — than to the field ring. |
| PagerDuty / Opsgenie / xMatters | two-way | client adapter | Where the customer already owns an alerting platform with on-call schedules, Helix feeds it by webhook and takes the acknowledgement back the same way. |
| Pager / TETRA / lone-worker devices | one-way | via gateway | Sector-specific reach (utilities, blue-light); the reply arrives on another channel. |
Beyond alerts: running whole processes over a channel
Section titled “Beyond alerts: running whole processes over a channel”Because replies normalise into ordinary Helix updates, a channel can carry more than a notification — it can carry a process. The standby callout is the built-in example: the call rings out, accept rewrites the roster and starts the shift, refuse releases the engineer and protects them from an immediate re-call, and silence past the contract’s answer window is handled for you.
The same shape extends to job deployment with no app at all: a resource that has no smartphone app and doesn’t want the web page can be offered work over WhatsApp or SMS — job details out, Accept/Decline back, then “on site” and “complete” prompts as the job progresses — each step an ordinary state change in the plan, visible to dispatch and the contact centre exactly as if it came from the Engineer App. This is a thin client extension on the framework, not a parallel system.
Integration flexibility
Section titled “Integration flexibility”The framework is deliberately vendor-neutral and edge-thin:
- Core never holds credentials — vendor keys live in your environment and your adapter, following the same secrets model as the rest of Helix.
- Adapters are small — outbound is one
send(); inbound is onereceive()that verifies the provider’s signature and hands back the reply. A WhatsApp or Twilio adapter is a page of code, and the worked examples are in the developer guide. - Your existing systems keep working — an external host that already runs its own callout or paging simply doesn’t enable the layer, or takes the webhook feed and answers on the reply URL. External responses always win.
Related
Section titled “Related”- Actions — the in-app half of the same decisions
- Engineer App — the field view, and the web-push target
- resourceParams — configuring the callout and its channels