Which Orchestration Items Are You Allowed to Push?

A stuck orchestration item has a button on it. The button says Complete Item.

Whether you are allowed to press it depends on something the item does not tell you.

Two Items, Two Opposite Correct Actions

Writing down how order activation is supposed to be tested surfaced a distinction I had been carrying informally for months, and had never once written on a test case.

The billing integration item must reach Completed on its own. You never push it. If it hangs, you stop, and the hang is the finding — you investigate why the order did not sync rather than clearing the item and moving on.

The provisioning integration item behaves the other way round. When it does not land, forcing it through with the manual Complete Item fallback is legitimate. That path exists deliberately. It is how the flow is expected to behave when the downstream system does not respond.

Same platform, same plan, same red status. Opposite correct actions.

What You Destroy by Pushing

The reflex for any red item is to complete it and carry on, because the visible goal is a plan that finishes.

Do that to the billing item and you have removed the only evidence that anything was wrong. The item exists precisely to catch "billing did not receive this order". Completing it by hand asserts that it did.

The order then moves forward. The plan finishes green. The screenshot goes in the test evidence. And the actual state of the world — an activated order the billing system knows nothing about — is now sitting behind a Completed status that says the opposite.

That is worse than a failed test. A failed test is information. This is a pass that was manufactured by the tester and then filed as proof.

The Distinction Is Invisible on the Item

Here is the part that makes this a design problem rather than a discipline problem.

Look at the two items side by side. Both have a name. Both have a status. Both are red. Neither carries any indication of which integration owns it, whether that integration self-completes, or whether the manual fallback is an intended path or an override.

The information that decides your action lives entirely outside the object you are looking at. It lives in someone's head, and usually in the head of whoever set the plan up.

So a tester who is new to the flow cannot derive the right action from the system. They can only guess, and the guess that fits the incentive — clear the blocker, finish the run — is the one that hides defects.

And Sometimes the Right Answer Is No Callout at All

There is a third mode, and it produces the opposite failure.

In one switch journey, the deprovision item autocompletes with its callout deliberately skipped. There is no integration call. Not a missing one — an absent-by-design one.

Testers internalise a simple rule early: every orchestration item fires its callout, so if you cannot find the callout, the integration is broken. Against that rule, this item looks like a clear defect on a flow that is working perfectly.

I have seen that raised. It is a costly kind of false positive, because it consumes a developer's investigation, it lands on a priority queue during a release window, and it teaches everyone involved that QA does not understand the orchestration layer — which makes the next real finding land softer.

The Register That Fixes Both

None of this is hard knowledge. It is unwritten knowledge, which is a different problem, and it has a cheap fix: a per-flow list of items with their completion mode.

• Record the owning integration for every item in the plan. Not the item name — the system on the other end of the callout, because that is what determines whether the item can be pushed.
• Record the completion mode explicitly: self-completing, manual fallback, or autocompleted with no callout. Three values, one column, and it resolves every stuck-item decision a tester will face in that flow.
• Record what to do when it hangs. "Investigate, do not complete" or "complete via fallback, note it in the run" — written next to the item, not left to judgement in the middle of an execution.

That table takes an afternoon to build with someone who knows the plans. It then answers a question that otherwise gets re-asked, re-guessed and re-answered differently every time a new tester joins.

Why This Class of Knowledge Escapes

Test cases describe what to do. They rarely describe what an intermediate state means.

A case says "submit the order and verify the orchestration plan completes". It does not say "if item four is red after ten minutes, that is your result — do not clear it". So the tester improvises, the plan goes green, and the case passes on the strength of an action that was never part of the case.

The deeper issue is that "drive every orchestration item to Completed" sounds like one rule. It is at least three, and which one applies is a property of the integration behind the item rather than of the item itself.

A tester who does not know which is which is not testing the integration. They are testing their own ability to make a plan turn green, and they will succeed at that every time.

In your current flow, which orchestration items are you allowed to push — and where is that written down?