Change request issues not consistently linked to originating defects

ALM Atlassian Jira Software
, , , , , , , ,
1

We have broken defect-to-change traceability that’s causing compliance audit failures. Our process uses separate projects for defects (DEF) and change requests (CHG), but the links between them are inconsistent.

Expected workflow:

  1. Defect identified and logged in DEF project
  2. Change request created in CHG project to address defect
  3. CHG issue should link to originating DEF issue with “relates to” link type

Current problems:

  • About 40% of change requests have no link back to defect
  • Some defects have multiple change requests but only one link
  • Manual linking during CHG creation often forgotten
  • No way to enforce linking at workflow level

Audit requirement: Every change request must trace to at least one defect for justification. We need to:

  1. Enforce linking when creating change requests
  2. Bulk fix existing missing links
  3. Generate audit reports showing orphaned changes

Example missing link scenario:


DEF-1234: Critical security vulnerability
CHG-5678: Deploy security patch (no link to DEF-1234)
Result: Audit can't verify change justification

Can we use workflow validators to enforce issue linking? How do we bulk fix hundreds of existing missing links using JQL?

2

For audit reporting, create a custom JQL filter that shows changes with their linked defects. Use the “issueFunction in linkedIssuesOf()” function to build traceability reports. Export to Excel and add columns for link type and linked issue summary. You can also build a Jira dashboard with gadgets showing linked vs unlinked change requests as pie charts for quick visibility.

3

For bulk fixing, use JQL to find orphaned change requests, then create links programmatically. First, find CHG issues without links:


project = CHG AND issueFunction NOT IN linkedIssuesOf("project = DEF")

Export that to CSV with the summary field. Then match summaries to defect keywords to identify likely parent defects. You’ll need a script or Jira automation rule to create the links in bulk once you’ve identified the matches.

4

We implemented the workflow validator and it’s working for new changes. For the bulk fix, we’re manually reviewing the orphaned changes and linking them. It’s tedious but necessary. Still need a good approach for the audit reporting part - how to generate reports showing change-to-defect traceability?

5

Here’s a complete solution for establishing and maintaining defect-to-change traceability:

1. Cross-Project Defect and Change Workflows: Modify your CHG workflow to include linking checkpoints at multiple stages:

  • Add “Defect Link” as a required field on the CHG create screen
  • Configure the field to only accept links from the DEF project
  • Add a workflow condition on the “Open to In Progress” transition that checks for at least one link
  • Add a post-function that validates the linked defect is in an appropriate state (not Closed)

This ensures traceability is established early and maintained throughout the change lifecycle.

2. Issue Linking Standards and Enforcement: Establish clear linking standards:

  • Use “relates to” link type for changes addressing defects
  • Use “blocks” link type when change is waiting on defect resolution
  • Document standard in project documentation and team wiki
  • Add link type descriptions in Jira admin settings to guide users

Create a linking policy that specifies:

  • Every CHG must link to at least one DEF
  • Multiple CHGs can link to same DEF (for phased fixes)
  • Links must be created during CHG creation, not later
  • Removing links requires manager approval

3. Workflow Validators to Enforce Related Issues: Implement these validators on your CHG workflow:

Validator on “Open to In Progress” transition:

  • Type: Linked Issues Validator
  • Configuration: Require at least 1 link of type “relates to” to project DEF
  • Error message: “Change request must link to at least one defect”

Validator on “In Progress to Done” transition:

  • Type: Parent Status Validator (using ScriptRunner or similar)
  • Configuration: Verify linked DEF issues are not in “Open” status
  • Error message: “Cannot complete change while linked defects are unresolved”

Add a workflow condition that prevents deletion of links:

  • Type: User is in Role condition
  • Configuration: Only “Change Managers” role can remove links
  • This prevents accidental link deletion that breaks traceability

4. Bulk Fixing Missing Links Using JQL: Identify orphaned change requests with this JQL:


project = CHG AND issueFunction NOT IN linkedIssuesOf("project = DEF") ORDER BY created DESC

Export results and analyze summaries to identify likely parent defects. Use pattern matching on keywords (“fix”, “security”, “bug”) to correlate with defect summaries.

For bulk linking, create a CSV file with format:


CHG-Key,DEF-Key,LinkType
CHG-5678,DEF-1234,relates to
CHG-5679,DEF-1235,relates to

Use Jira REST API or a CSV import tool to create links in bulk. Script example approach:


POST /rest/api/2/issueLink
{
  "type": {"name": "Relates"},
  "inwardIssue": {"key": "CHG-5678"},
  "outwardIssue": {"key": "DEF-1234"}
}

For changes where the parent defect is unclear, create a “Research Required” label and assign to change managers for manual investigation. Don’t guess at links - ensure accuracy for compliance.

5. Audit and Compliance Traceability: Create a comprehensive audit reporting system:

Dashboard Gadgets:

  • Pie chart: Linked vs Unlinked Changes (last 30 days)
  • Filter results: Orphaned changes requiring attention
  • Two dimensional filter: Changes by link type and status

Scheduled Reports: Weekly report showing:


project = CHG AND created >= -7d AND issueFunction NOT IN linkedIssuesOf("project = DEF")

Email this to change managers every Monday for follow-up.

Monthly compliance report showing:


project = CHG AND resolved >= -30d

Export with custom columns: Key, Summary, Linked Defects, Link Type, Resolution Date

Generate a traceability matrix in Excel showing defect-to-change relationships.

Audit Trail:

  • Enable issue link change notifications in audit log
  • Create an automation rule that posts a comment when links are added/removed
  • Log link changes to a separate audit project for compliance tracking

Compliance Validation: Create a quarterly validation process:

  1. Run JQL to find all changes from quarter
  2. Verify each has at least one defect link
  3. Spot-check 10% of links to verify accuracy
  4. Document results in compliance report
  5. Address any gaps with corrective action plans

Additional Recommendations:

  • Train team on linking standards during onboarding
  • Add linking reminder to CHG creation template
  • Create a “Quick Link” button on CHG view screen for easy defect lookup
  • Implement a pre-approval checklist that includes “Verify defect link”
  • Set up automation rule that notifies change manager when CHG is created without links

This comprehensive approach ensures both forward-looking enforcement and backward-looking correction of your traceability issues. The combination of workflow validation, bulk correction, and ongoing audit reporting provides the compliance framework you need.

6

From a compliance perspective, you need more than just technical linking. Document your linking standard in a policy, train the team, and implement regular audits. The workflow validator helps enforce it going forward, but you also need a monthly report that shows any orphaned changes so they can be investigated and linked properly. Make linking part of your change approval checklist.

7

Yes, workflow validators can enforce issue linking. Add a “Linked Issues Validator” to your CHG workflow on the transition from “Open” to “In Progress”. Configure it to require at least one link of type “relates to” pointing to an issue in the DEF project. This prevents change requests from progressing without proper traceability. The validator is available in Jira 9 core functionality, no plugins needed.

8

That validator approach sounds good for new change requests. But how do we handle the existing 400+ change requests that are already in progress without links? We can’t block them retroactively. Need a way to identify and fix them in bulk.