Updated Nov 5, 2026
2 min readWorkflow across systems: make decisions explicit.
A status mapping is not a decision process. What a Teamcenter–Polarion integration teaches about ownership, pending decisions and recovery.
PLM Nexus technical team
- Decision requestedPolarion
- Approval pendingThe responsible team decides
- Communicate the outcomeKeep the systems aligned
Process diagram
Our Teamcenter–Polarion work for CNH included integration and workflow coordination. The general lesson is that exchanging a status is not the same as coordinating a decision.
Model the pending decision explicitly
In a cross-system workflow, represent pending decisions explicitly. Agree who can decide, what each outcome means and how it is communicated.
Define who can decide, then map the data
For each transition, identify the originating system, the decision owner and the response expected by the other system. Separate “request received” from “decision accepted”. A technically successful service call can still leave the business process waiting for a person.
Test the branches, not just the exchange
For a new integration, include approval, refusal, a repeated notification and a service failure in the test plan. Agree the visible state and recovery action for each. These scenarios extend the design lesson; they are not presented as historical test results for CNH.
AI can accelerate the mapping, code and test preparation. The team still has to decide which system owns each transition and prove the resulting behavior. That is useful governance: clear decisions embedded in the workflow, not another document detached from implementation.
These are proposed acceptance checks, not completed tests or customer results. Set the expected behavior with the process owner, record the environment and version, then fill in the observed result and evidence. Blank cells are not passes.
| Scenario | Expected result | Evidence to retain |
|---|---|---|
| Request received | The receiving system records pending; receipt is not approval. Name the decision owner. | Correlation ID and pending state in both systems. |
| Approval or refusal | Only the authorized owner decides; both outcomes have distinct mapped states. | Actor, decision, timestamp and corresponding state. |
| Duplicate notification | Replaying the same event does not repeat the business transition. | Event key, replay and single transition record. |
| Delivery failure | Keep a visible pending/error state, named recovery owner and retry policy; do not report success. | Failure log, retry key and reconciled final state. |
Next step
If this pattern is showing up in your Teamcenter environment, explore the relevant service or discuss the change you need.