In Ignition 8.1.47, a user whose schedule becomes active after an alarm starts does not receive that alarm through the tested notification pipeline. Treat the schedule change as a separate dispatch event; the alarm’s transition to active does not, by itself, guarantee another roster evaluation.
Approach comparison for schedule changes
Choose how to trigger a second recipient evaluation before designing notification logic. The reported behavior distinguishes an alarm-state event from a roster schedule change: an alarm can remain active while the eligible user roster changes.
| Approach | Trigger and behavior | Trade-off |
|---|---|---|
| Default alarm-triggered pipeline | Starts when the alarm state changes. A user inactive at that point is missed if the pipeline does not run again when the schedule becomes active. | Simple, but does not address a later roster change in the observed configuration. |
| Pipeline loop or repeated schedule checks | Keep the pipeline running or check schedules over time so it can reevaluate eligible users. | Can detect later schedule changes, but time-loop logic becomes difficult to manage for complex schedules. Re-entering the pipeline to re-pull the roster was suggested, not verified. |
| Schedule-change dispatcher with SQL tracking | At roster-change time, read current active alarms and the record of recipients already notified; dispatch to eligible recipients who have not been notified. | Separates alarm and schedule events, but requires persistent state and careful handling of alarm clears, acknowledgements, and duplicate dispatches. |
For shift handoff or lunch-break coverage, use a schedule-change dispatcher when the requirement is to notify newly active users about alarms that remain unresolved. Keep the default pipeline for initial alarm dispatch if it already meets that need. Use a loop only when its schedule logic is maintainable and its behavior has been tested.
Notification state for unresolved alarms
Define the resend policy before implementing the dispatcher. A useful policy is to notify a newly active roster member once for each still-active, unacknowledged alarm, while suppressing repeat notifications to users already notified for that alarm. This matches the desired behavior described for shift changes; it is a design choice, not a built-in guarantee.
Model the decision around three facts: whether the alarm is currently active, whether it has been acknowledged or otherwise handled according to the site’s rule, and whether this recipient has already received a notification for it. The notification record must distinguish the alarm from the recipient so later roster changes can find new recipients without resending to everyone.
Decide what acknowledgement means in this workflow. If acknowledgement ends redistribution, exclude acknowledged alarms at schedule-change time. If another pipeline state defines “dealt with,” use that state instead. Do not treat schedule activation alone as proof that an alarm needs a new notification.
Schedule-change dispatcher procedure
Implement the dispatcher as an event that runs when a roster schedule changes to active. The reported SQL design also uses active and clear pipelines to maintain active-notification records. Confirm each stage before enabling dispatch broadly.
- Set the dispatch rule. Specify which active alarm states qualify, whether acknowledgement suppresses dispatch, and whether users already notified for an alarm are excluded. Confirm the rule against a written test matrix before creating database logic.
- Create persistent tracking. Store enough information to identify each active alarm and each recipient already notified. Confirm that an alarm can be matched to its tracking record after an activation, clear, or schedule change; do not rely on a record that cannot be reconciled to current alarm state.
- Connect alarm lifecycle updates. Configure the active pipeline to add or update the active record and the clear pipeline to remove or close it. Confirm that a test alarm appears on activation and is removed or marked closed on clear.
- Trigger at roster activation. Configure a scheduled event for the relevant roster-change time. Have it read the current active alarms and eligible roster, then select only qualifying alarm-recipient pairs not previously notified. Confirm that the event runs at the intended schedule transition and sees the new active roster.
- Dispatch and record the result. Send the notification and record that recipient as notified for the alarm. Confirm the chosen record update and notification behavior on a controlled test; the implementation must prevent a later run from selecting the same recipient again.
- Reconcile before production use. Compare tracked active records with current alarm state and repair stale or orphaned records. Confirm that an alarm cleared before a schedule event is not sent, and that a still-active qualifying alarm reaches a newly active, previously unnotified recipient.
Loop-based schedule checks
A loop can keep the pipeline alive long enough to revisit eligibility, or it can explicitly check times and schedules. This avoids maintaining a separate active-alarm dispatch event, but couples schedule evaluation to pipeline logic. The reported workaround used time checks in loops and was described as painful to manage for more complex schedules.
If using this approach, write down the schedule transitions and resend rules first. Check that every loop iteration refreshes the roster rather than reusing recipients captured when the alarm first activated. Test an alarm that remains active across inactive and active schedule phases, including the rule that already-notified recipients should not receive repeated messages. Re-pulling the roster by restarting the pipeline is a possible design, not an established behavior; verify it in the target project before relying on it.
Alarm and schedule event separation
The failure occurs because two state changes are involved: the alarm becomes active, and later a user’s schedule becomes active. A pipeline initiated by the alarm transition may evaluate the roster once and then have no trigger to reconsider recipients when schedules change. The new schedule state alone is not necessarily an alarm event.
This distinction explains why checking the alarm’s active state is not enough. Dispatch needs both a current-alarm query and a current-roster query at the time the schedule changes. Persistent tracking supplies the third input: who has already been notified. Without that history, repeatedly evaluating active alarms can either miss new users or resend to users who already received the notification.
Failure patterns and diagnostic checks
| Observed result | Likely mechanism | Check |
|---|---|---|
| No message when a user’s schedule activates | The alarm pipeline ran when the alarm changed state, before that user became eligible. | Compare alarm activation time, pipeline execution, and schedule activation; confirm whether any event reevaluates the roster after the schedule change. |
| New shift receives no unresolved alarm | No schedule-change dispatcher or effective roster refresh ran. | Check the schedule event execution and the roster it reads at dispatch time. |
| Previously notified users receive duplicates | Dispatch does not filter on per-recipient notification history. | Inspect the alarm-recipient tracking state and confirm it is updated after dispatch. |
| Cleared alarms are sent at a later schedule change | Active records were not removed or reconciled when alarms cleared. | Confirm clear-pipeline updates and compare records against current alarm state before dispatch. |
| Loop logic becomes difficult to maintain | Schedule rules are embedded as repeated time checks in pipeline logic. | Inventory schedule transitions and compare the maintenance burden with a separate schedule-change dispatcher. |
Commissioning verification
Run these tests with controlled alarms and test recipients before relying on the behavior for shift coverage. Record timestamps, roster eligibility, acknowledgement state, dispatch outcome, and tracking state at each transition.
- With the recipient schedule inactive, activate an alarm. Confirm that the recipient is not selected by the initial pipeline.
- Keep the alarm active and make the recipient schedule active. Confirm the schedule-change event reads the now-active roster and sends one notification if the alarm still qualifies.
- Run the same schedule event again with no state change. Confirm the same alarm-recipient pair is not sent a duplicate.
- Repeat with the alarm acknowledged before schedule activation. Confirm the configured acknowledgement rule suppresses or permits dispatch as intended.
- Clear the alarm before schedule activation. Confirm that the dispatcher does not send a notification for the cleared alarm and that its active tracking record is closed or removed.
- Keep an alarm active across multiple schedule cycles. Confirm each newly active, not-yet-notified user receives one notification, while previously notified users do not receive another.
FAQ
Why does a user miss an alarm when their schedule becomes active?
The tested pipeline evaluates the roster when the alarm activates, while the user is inactive. A later schedule change does not automatically cause another alarm-state evaluation.
Why doesn’t an active alarm trigger another notification at shift change?
The alarm remained active, so no new alarm activation occurred. Add a schedule-change dispatch event or a tested pipeline loop that refreshes the roster.
How do I notify a new shift without resending to the old shift?
Track notification status per alarm and recipient. At schedule activation, select only qualifying active alarms and recipients without a prior notification record.
Should an acknowledged alarm be sent to a newly active user?
Set this as an explicit dispatch rule. If acknowledgement means the alarm is handled, exclude acknowledged alarms when the schedule-change event evaluates current alarms.
How do I verify the schedule-change notification fix?
Keep a test alarm active while an inactive recipient becomes active, confirm one dispatch, then rerun the event and confirm no duplicate. Finally, verify cleared and acknowledged alarms follow the configured rule.