Documentation / Version 1.0

From incident to evidence-backed review.

1. Configure the source project

After installing the app, a Jira project administrator opens Project settings → Apps → AfterIncident configuration. Enable the app and select the source issue types. In Jira interfaces that use “space” terminology, use Space settings.

The setup form displays the source project's issue-type and workflow-status IDs. Set the action project ID, a non-subtask action issue type, implemented statuses and optional cancelled statuses. Choose a native link type (for example, Relates). Use numeric IDs, not names.

Set the default evidence requirement and review delay. Zero means no effectiveness review. Native actions must use a Jira create screen that supports any fields you supply, including due date, assignee and priority.

2. Create corrective actions

Open a configured source incident and choose AfterIncident from the issue's app panels. Expand “Add corrective action”. Enter the title, optional description, owner, due date, action type, evidence requirement and review interval. A native Jira issue is created in the configured target project.

Users need permission to view and edit the source and to create actions in the target project. Jira workflows and issue-security rules still apply. Repeating a failed request with the same form mutation does not intentionally create another issue.

3. Implement and provide evidence

Move the action through its normal Jira workflow. When it reaches a configured implemented status, AfterIncident reconciles the change asynchronously. Use Refresh after allowing time for the event to be processed.

If evidence is required, the action stays “Implemented awaiting evidence” until available evidence exists. Add an HTTPS URL, short note, or numeric ID of a comment or attachment on that action. Verification records an additional human acknowledgement; it is not an electronic signature.

4. Review effectiveness

The review interval starts when the action is eligible: implemented and, when required, supported by evidence. An hourly scan marks overdue reviews due. A delayed platform execution can make a review appear after its exact due time.

Optional recurrence rules combine the source project, source issue types, post-implementation time window and configured component, service-field, label or JQL restrictions. Candidates are bounded by the configured maximum, so they are not an exhaustive incident investigation.

Confirm or dismiss candidates, choose a human result and optionally add a rationale. Completing a review preserves its decision and signal snapshot. “Reopen review” creates another review while retaining the earlier result.

5. Use the dashboard

Open AfterIncident from the project navigation. Review overdue actions, evidence gaps, due reviews, ineffective or partially effective results and median implementation time. Metrics include only actions and source incidents the current user can access.

Reopening, deletion and troubleshooting

• Reopening a Jira action cancels a pending review and starts a new implementation cycle. Completed reviews remain historical.
• Removing a native issue link produces a warning with a Restore link control.
• Deleting a source does not delete its native Jira actions. Deleting an action cancels future reviews; the app does not recreate it.
• Run diagnostics after changing workflows, issue types or link types. The app does not automatically modify your Jira configuration.
• If a Jira creation has an uncertain outcome, do not submit a new action form. Send the displayed mutation reference to support so the already-created issue can be recovered without duplication.

See privacy and retention, terms of use, or contact support.