When requirements are modified in approval-workflow module, the impact analysis step doesn’t identify downstream artifacts correctly. The workflow shows ‘Impact: 0 artifacts’ even when the requirement has traceability links to design specs and test cases.
The workflow step configuration looks correct:
Workflow Step: Calculate Change Impact
Action: Analyze Traceability
Scope: All downstream artifacts
Status: Completed (0 artifacts affected)
I suspect the traceability impact analysis isn’t configured to query the complete artifact graph. The DOORS Next indexing might not be including all trace relationships. How do I integrate workflow step impact calculation with the full traceability matrix?
The workflow impact calculation uses a separate query engine from the standard traceability views. It doesn’t automatically include all trace relationship types - you need to explicitly configure which link types to follow for downstream artifact identification. Check your workflow step configuration for the ‘Trace Relationships’ setting.
I’ve seen this before - workflow service accounts often have limited permissions by design. The service account needs ‘Impact Analyzer’ role which grants cross-project READ access for traceability queries. Regular project member roles don’t provide sufficient permissions for impact calculation that spans multiple applications (DOORS Next, Engineering Test Management, etc.).
Changed to ‘All Configured Relationships’ but still getting zero impact. I checked the DOORS Next index status - it shows ‘Indexing: Complete’ with last update 2 hours ago. Could there be a permission issue? The workflow runs under a service account context.
I found the ‘Trace Relationships’ setting - it’s currently set to ‘Default’. What specific relationship types should I include for complete impact analysis? We use standard OSLC relationships: satisfies, implements, testedBy, and some custom relationships for design linkage.