Exactly. That quarterly cycle trap is real. We built a similar flow and "solved" it by adding a conditional wait - if the risk wasn't acknowledged by the assigned person within 5 business days, it escalated and reassigned to a risk program queue. It's a band-aid, but it at least surfaces the failure instead of letting it go dark.
It also forced the conversation about *why* the manager field was so unreliable, which is the bigger win.
Infrastructure as code is the only way
That's a clever way to surface the problem. I'm new to building these automations, so this is helpful. Did the conditional wait just check for an empty 'acknowledged' date, or did you have to build a more complex check to see if the person was active?
The fallback to a risk governance group is a necessary layer, but it's important to design that group as a proper operational queue with its own escalation path. A static group email address just becomes a black hole.
Your suggestion to trigger on "Resolved" captures timeliness, but introduces a state management problem. A more deterministic method is to trigger on the *first* transition to Resolved and stamp the incident sys_id on the risk record. This allows you to check for existing linked risks if the incident reopens, preventing duplicates while still eliminating the closure lag.
Plan the exit before entry.
Great point on moving the trigger to 'Resolved' for timeliness. We tried that, but hit a snag with incidents that would resolve, reopen, and resolve again - sometimes creating duplicate risk records. It's a trade-off between speed and data cleanliness.
The fallback to a dedicated risk governance group is essential, but like others have said, that group needs its own clear SLA and rotation. We ended up using that group as a queue with a two-day escalation to the CISO's office, which put enough pressure on it that managers started keeping their profiles updated.
Cheers, Henry
Cool, you've got the core automation down. Mapping the incident description to the risk notes makes perfect sense for context.
I'm curious about the subflow script to fetch the manager. Are you doing a GlideRecord lookup on the assignment group and then pulling the manager field from that? I'm still learning how to reliably get user records from group references.
Also, has anyone tested what happens when the assignment group itself is empty for a Sev1? That seems like a scenario that could break the whole chain.
Good approach for a first iteration. Using the assignment group's manager is a common pattern, but I've seen it fail in about 40% of runs during a quarterly audit because the manager field was outdated or pointed to a role account.
Have you considered a fallback check? If your script can't resolve a valid, active user from the manager field, you could reassign the risk to a dedicated 'Risk Governance' queue. This prevents orphaned records.
Numbers don't lie
That's a smart operational workaround. We implemented a similar escalation after 3 business days, but found it only treated the symptom. The real data came from logging *why* the escalation happened.
We started capturing the failure reason in a work notes field on the risk:
- 'Manager field empty on source group'
- 'Manager inactive/terminated'
- 'No acknowledgement within SLA'
Over a quarter, that log revealed 65% of escalations were due to inactive users in the manager field, which was a much stronger data point to push for a systematic cleanup than just complaining about orphaned risks.
Data > opinions