Notification Limiting & Scheduling
under consideration
M
Matthew Buehlmann
This would be a huge improvement for us! Came to suggest and saw that it was already here. Direct integration into paging apps (e.g., SIGNL4) would be a plus. Without that integration, maintaining parity between on-call rotation (which frequently changes/has people covering for one-another) and AutoElevate configuration would be a burden.
Another approach to this feature that would prevent the need for complex technician routing, would be to offer up an alternate message for after hour/holiday/weekend requests.
E.g., Set the business dates/hours and outside of that have a message like: "Your request has been received, but this is an after-hours request that may not be processed until regular business hours. If this is an emergency, please use
XYZ EMAIL/PHONE
to trigger an emergency support request from an on-call technician"This would let us fall back to our existing on-call system, rather then building the whole thing out in CyberFox again.
D
Daniel Rivera
Matthew Buehlmann: Thanks Matthew — this is exactly the kind of real-world scenario we asked for.
The after-hours fallback message is a smart angle: setting business hours/holidays and showing requesters a configurable message pointing to your existing emergency channel would deliver most of the value without you having to mirror on-call rotations in AutoElevate. We've added that approach to our evaluation alongside the schedule/routing model discussed above.
Noted on paging-app integration (e.g., SIGNL4) as well — direct integrations are a bigger lift, which is part of why the fallback-message idea is appealing as a nearer-term option.
Still under consideration with no timeline to share, but this thread is directly shaping how we scope it. Keep the scenarios coming.
Owen Parry
Thanks for the great feedback — notification control is an important area for MSP workflows, especially for teams managing multiple clients and on‑call rotations.
AutoElevate’s current notification system doesn’t yet support working‑hour schedules, holiday suppression, or technician‑specific time‑based routing. We understand this creates noise, especially for larger NOC/SOC or after‑hours teams.
We are actively reviewing a more granular notification model that would support:
* Technician working hours and holiday schedules
*Notification routing by Company, technician group, or role
* Time‑based rules (on‑call windows, overnight suppression, etc.)
* Optional mode to hide new requests in the mobile app for tech‑only workflows
* Configurable visibility so teams use the portal without unnecessary alerts
These capabilities are under consideration, and feedback here directly helps shape priority.
Call to action for additional feedback here: Please share your specific scheduling needs (e.g., on‑call rotations, holiday blackout periods, per‑company tech assignments). Real‑world scenarios help us design the right flexibility into the system.
David Gunther
Mobile app setting to remove visibility for all new requests so it is strictly technician mode so techs are required to use portal, but not have visibility of requests.
Dave Sibiski
updated the status to
under consideration