v8.1.47
I’m playing with user schedules and alarm notification pipelines, and I noticed that if an alarm goes active while a user schedule is inactive the user isn’t notified (obvious). But if the alarm remains active and the user schedule becomes active, I expected (hoped?) the notification pipeline would see this and send the user the notification once their schedule changes to active, but upon testing it didn’t do this.
Perhaps this is a feature request.
I can see this as being an issue, for example you can configure lunch breaks, and during lunch if an alarm goes active users won’t ever get a notification for that alarm 
Working around this by ignoring schedules and instead checking times in loops in the pipeline works, but it’s painful and impossible to manage for more complex schedules.
How would you handle the case of an alarm that has been active a while on a shift and then the next shift's schedule goes active? Would you want those alarms to resend notifications?
Would you have a cutoff time, where if the alarm has been active <x time before a schedule becomes active, it sends a new notification to the now active user(s) of that schedule?
I guess you could always filter them off their acknowledgement state, and re-notify if the alarm hasn't been acked and a new schedule has become active.
I think yes, I would want the new shift to get the notifications if the alarm hasn’t been dealt with (at least acknowledged).
But users who have received alarms once shouldn’t get them again if an alarm goes active and stays active over cycles of schedule active/inactive phases.
To me, all users in the roster should eventually get the notification if the alarm remains active unack (or whatever the pipeline state is attached to). At least, it should be the default option.
I think the key would be that you'd have to have the pipeline loop go back to the start so it can re-pull the roster. But not sure without playing with it.
I guess the problem here is that the roster doesn’t activate the pipeline, the change of alarm state does. So unless you try and stay in the pipeline for the duration of the alarm, constantly looping and checking the roster, you won’t get what you want. I think you will need to develop your own system for handling this. You could create a table in SQL to track active notifications and a list of who’s been notified. Your active and clear pipelines can add/remove records, then have a scheduled event that runs at roster change time, read the current active notifications and see if you need to notify anyone new. Wouldn’t be too hard, but it’s not trivial. Lots of edge cases that could lead to orphaned records, you would have to validate heavily.