Here’s a complete automation solution that handles all your duplicate prevention and reopen scenarios:
Automation Rule Triggers and Conditions:
Your current trigger fires on every transition to “Escalated,” which causes duplicates. Refine it:
- Trigger: Issue transitioned
- Condition 1: Status changed FROM any status TO “Escalated” (use
{{issue.status}} and {{changelog.status.fromString}})
- Condition 2: Priority equals “Critical”
- Condition 3: Labels contain “production-issue”
- Condition 4 (Guard Check): Custom field “Linked Defect Key” is EMPTY
This ensures the rule only fires on the first escalation, not on subsequent updates to an already-escalated incident.
Cross-Project Defect Creation from Incidents:
Use the native “Create issue” action in Jira automation:
- Project: DEV
- Issue Type: Bug
- Summary: `Production Issue: {{issue.summary}}
- Description: Copy from incident with context:
Originated from incident: {{issue.key}}
Reported by: {{issue.reporter.displayName}}
Incident description:
{{issue.description}}
- Priority: Map from incident priority
- Labels: Add “auto-created” and “production-defect”
Link-Based Guard Checks to Avoid Duplicates:
After creating the defect, add these actions in sequence:
- Create issue link: Link the new defect to the incident using “is caused by” link type
- Edit issue (incident): Set custom field “Linked Defect Key” to `{{createdIssue.key}}
This creates a bidirectional reference-the link provides traceability in Jira UI, while the custom field enables automation guard checks.
Custom Field for Storing Created Defect Key:
Create a custom field on the incident issue type:
- Type: Text Field (single line)
- Name: “Linked Defect Key”
- Context: Service Desk project, Incident issue type only
- Make it read-only on create/edit screens so users can’t modify it manually
This field acts as the duplicate prevention flag. The automation rule checks this field before creating a defect.
Service Desk and Dev Project Integration:
For reopened incidents, add a second automation rule:
- Trigger: Issue transitioned to “Reopened”
- Condition 1: Custom field “Linked Defect Key” is NOT EMPTY
- Action 1: Lookup issue using
{{issue.Linked Defect Key}} (use “Lookup issues” action)
- Condition 2: Branch rule on lookup results, check if
{{lookupIssues.status}} equals “Closed” or “Done”
- Action 2 (if defect closed): Create new defect (same as original rule) and update custom field with new key
- Action 3 (if defect open): Add comment to existing defect: “Related incident {{issue.key}} was reopened on {{now}}”
This handles the reopen scenario intelligently-reusing open defects, creating new ones when the original defect was already resolved.
Advanced: REST API Alternative:
If you need more control (e.g., checking multiple linked defects, complex duplicate detection logic), use a “Send web request” action to query Jira REST API:
GET /rest/api/2/issue/{{issue.key}}?fields=issuelinks
Parse the response to check if any linked issue with type “Bug” and link type “is caused by” already exists. This is more robust than relying on a custom field, but requires JSON parsing in subsequent automation actions.
Complete Rule Structure:
[Rule 1: Create Defect on Escalation]
TRIGGER: Issue transitioned to Escalated
CONDITION: First time in Escalated (check changelog)
CONDITION: Priority = Critical AND Labels contains production-issue
CONDITION: Linked Defect Key is EMPTY
ACTION: Create issue in DEV project (Bug)
ACTION: Link created defect to incident (is caused by)
ACTION: Set Linked Defect Key = {{createdIssue.key}}
[Rule 2: Handle Reopened Incidents]
TRIGGER: Issue transitioned to Reopened
CONDITION: Linked Defect Key is NOT EMPTY
ACTION: Lookup issue {{Linked Defect Key}}
BRANCH: If lookup status = Closed/Done
ACTION: Create new defect
ACTION: Update Linked Defect Key
BRANCH: If lookup status = Open/In Progress
ACTION: Add comment to existing defect
Testing Checklist:
- Escalate a new incident → Should create defect and set custom field
- Update the same incident while still Escalated → Should NOT create duplicate
- Transition incident away from Escalated and back → Should NOT create duplicate (custom field still populated)
- Reopen incident with open linked defect → Should add comment, not create new defect
- Reopen incident with closed linked defect → Should create new defect and update custom field
This solution eliminates duplicates via the custom field guard check, handles reopens intelligently by checking defect status, and maintains full traceability between Service Desk incidents and development defects. The approach uses only native Jira 9 automation features-no Script Runner or REST API required for basic implementation, though the REST API option is available for advanced duplicate detection scenarios.