Backlog items in ELM 7.0.3 not linking properly to requirements after global configuration sync

ALM IBM Engineering Lifecycle Management
, , , , , , , ,
1

We’re experiencing a critical issue after syncing our global configuration baseline in ELM 7.0.3. Backlog items imported from DOORS Next requirements are failing to maintain proper traceability links.

The problem occurs specifically when:

  • Requirements are imported from a baseline in DOORS Next
  • Backlog items are created in Engineering Workflow Management
  • Global configuration is synced to align component streams

After the sync, the backlog items show “Link Not Found” errors when trying to navigate to source requirements. The attribute mapping appears correct in our configuration, but the baseline link matching seems to break during the sync process.


Error: CRJAZ1234E Unable to resolve link target
Resource: /rm/resources/TX_abc123
Baseline: Sprint_15_Baseline

This is blocking our sprint planning as we can’t trace work items back to their originating requirements. Has anyone encountered this with global configuration syncs and found a way to repair the broken links?

2

Good catch on the configuration context. Also worth checking if the attribute mapping includes the configuration context field. I’ve seen cases where custom attribute mappings omit this and links break on any baseline change.

Run a quick test: create a new backlog item manually with the correct context and see if the link resolves. If it does, you know it’s a context issue with the existing items rather than a fundamental link problem.

3

I dealt with this exact scenario last month. The problem is that baseline link matching doesn’t automatically remap when you change the global configuration stream context. You need to update the configuration context for your backlog items to match the new baseline.

Go to your project area configuration and verify the default configuration context. If it’s still pointing to the old stream, that explains why links aren’t resolving. The link repair utility won’t help until the configuration context is aligned.

4

I’ve seen similar behavior with baseline references. Check if your global configuration is pointing to the correct component baselines. Sometimes the sync updates the GC but individual components don’t resolve properly.

Can you verify the baseline URIs in both DOORS Next and EWM are using the same global configuration context? The error suggests a resource resolution issue rather than a pure link problem.

5

Thanks for the suggestion. I checked the baseline URIs and they do reference the same global configuration. However, I noticed the component baseline in DOORS Next is using a different stream context than what EWM expects.

The requirements were imported from Stream A but our global configuration now points to Stream B after the sync. Could this stream mismatch be causing the link resolution to fail? The attribute mapping configuration looks correct, but maybe it’s not handling the stream context change properly.