Configure from the problem you see

Review bottleneck

Example: code review should move within one day, while legal approval normally takes five.

1. Open Flow Guard setup → Detection policy.
2. Keep active-status aging at 72 hours as the fallback.
3. Under Status-specific aging thresholds, add:

Peer Review = 24
Legal review = 120

Preview and confirm that review issues appear without making legal approval noisy. If many are dismissed as Expected workflow next week, lengthen that status threshold.

Cross-project dependency

Example: one payment blocker stops work in APP, WEB, and OPS.

1. Open Detection policy → Per-status and dependency rules.
2. Set the Jira link types that mean “this issue blocks another.” The default is Blocks.
3. Keep blocked duration at 24 hours.
4. Preview and confirm the downstream projects in the top finding.

Flow Guard follows visible links up to five hops. More active downstream work, especially across projects, raises the intervention priority.

Release risk

Example: a release is seven days away, but only a few remaining issues are actually stuck.

1. Confirm the Jira version has an unreleased release date.
2. Keep Release at risk at 168 hours.
3. Keep Due soon at 48 hours for issue-level deadlines.
4. Check the site time zone in Scope, then preview.

The release signal appears only when the issue already has a flow risk. Healthy work is not added merely because release week started.

Sprint carryover

Example: the same unfinished issue moves from one completed sprint into the next.

1. Open Detection policy.
2. Turn on Sprint carryover detection.
3. Preview and confirm Jira Software exposes the closed-sprint history.
4. Review carryover together with aging and inactivity; independent signals corroborate the risk.

Next week, watch Recurrences. Repeated recurrence suggests a workflow cause rather than a one-off issue.

Unassigned active work

Example: an issue is in progress, but the assignee is empty.

No threshold is required. UNASSIGNED_ACTIVE is a built-in 15-point coordination signal and becomes more urgent when aging or inactivity also fires. Assignment remains an explicit user action, limited to users Jira confirms are assignable.