Before
Closed incidents required a separate manual checklist to confirm their original locations and determine which cases still needed verification. Teams had to review recent closures, match occurrences to Jira or Confluence, avoid duplicate checks, and pass selected cases to verification individually.
How it works
- Receive a secure trigger and retrieve incidents resolved during the configured lookback period.
- Match occurrences to Jira or Confluence, exclude incidents already marked as verified, and group the remaining cases for review.
- Send each eligible case to the verification workflow and produce a consolidated summary of the results.
Workflow details
- Trigger and scope: The workflow starts when an on-demand secure webhook is received; its documented production schedule is hourly, and each run examines incidents resolved within the previous 24 hours.
- Incident review: It reads recently resolved incidents and their occurrences, then checks whether each occurrence belongs to the configured Jira or Confluence source types.
- Eligibility filtering: The workflow keeps only incidents that are recently resolved, linked to the relevant source types, and not already marked as verified, preventing duplicate verification work.
- Verification handoff: Each selected incident is grouped with its matching occurrences and passed to the incident verification workflow, with up to two verification cases processed concurrently in the configured flow.
- Run reporting: The workflow counts the cases checked and returns a summary showing how many incidents were recently resolved, how many matched Jira or Confluence, and the outcome for each verification case. No human approval step is defined in the flow.
What changed
Eligibility checks and case grouping now happen automatically after the trigger, so only recently resolved, relevant, and unverified incidents reach the verification workflow. The process ends with a single summary containing counts and per-incident outcomes instead of a separate manual checklist.
Work removed
Reviewing recently resolved incidents one by one, matching closed incidents to their Jira or Confluence occurrences, checking whether verification was already completed, grouping occurrences by incident, manually handing cases to the verification workflow, and compiling the run summary.
Expected outcome
A consistent post-closure review queue is created for every run, with eligible cases handed off automatically and up to two verification cases processed concurrently in the configured flow.
