"Order Submitted" Is Not "Order Succeeded"

The confirmation screen was green. The order had failed.

Not immediately, and not visibly. It failed a few seconds later, inside a work item nobody had opened.

Two Results Wearing One Name

Submitting an order in a Salesforce CPQ or order management stack produces two outcomes, and they arrive at different times.

The synchronous one is the screen. The cart validated, the record saved, the confirmation rendered. That result is immediate and it is the one testers screenshot.

The asynchronous one is the Orchestration Plan. Provisioning tasks, external callouts, notifications, billing handoffs — a chain of work items that starts running after the screen has already told you everything went well.

A tester who stops at the confirmation has verified the first result and nothing about the second. And the second is where the failures that reach customers live.

Two Ways This Shows Up

The work item that fails on its own. An order submitted cleanly, and the Activation Link Customer Notification work item failed inside the plan. The order looks complete in every list view. The customer never receives the link they need. Nothing on the submit screen hints at it, and no exception surfaces to the agent who placed the order.

The product that was never orderable. A new discount line item was configured in Salesforce. It appeared in the cart, priced correctly, passed the whole happy path, and submitted. Then the Create Order work item to the billing system failed with externalCatalogPlanId is invalid.

The second one is worth sitting with. Every Salesforce-side check was green. Selectability, pricing, cart behaviour, submit — all correct. The product simply had no valid mapping in the downstream catalog, and there is no cart-side test that can discover this, because the cart genuinely does not know.

The Salesforce side was done. The product was un-orderable.

The Rule

Testing a new product, discount or charge is not finished when it drops into the cart. It is finished when the orchestration plan completes end to end.

Every work item is its own assertion. The submit screen tells you nothing about any of them.

How to Test It Without Guessing

Orchestration plans are intimidating the first time you open one. The practical routine is short.

• Open the plan and read the shape before you assert anything. Which items exist for this cart composition? Plans branch — hardware introduces shipment items, subscription-only add-ons may introduce none at all. The set of items you expect is a function of what is in the cart, not of the journey name.
• Know which items complete themselves and which you are allowed to push. Some integrations must reach Completed on their own; forcing one manually hides a real defect behind a green tick. Others have a legitimate manual fallback. Confusing the two means passing a broken integration. Write this down per item type, once, for the whole team.
• Know which items skip their callout by design. Some plans deliberately auto-complete an item without calling anything. If that is not documented, every one of them becomes a phantom bug filed by whoever is new.
• Assert the payload, not just the status. An item that reaches Completed with a field missing from its payload is a defect that will surface two systems later, wearing a different name.
• Give async work a documented wait and a refresh step. A test that asserts "Completed" one second after submit is racing the system, and it will pass or fail depending on the day. That is worse than no test.

Why This Escapes So Reliably

The failure has every property that helps a defect survive.

It is invisible on the screen the tester was told to check. It happens after the moment everyone treats as "done." It produces no error for the agent, no exception in the UI, and often no alert anywhere until a customer calls to ask why nothing arrived.

And crucially: the story that introduced the product was written about Salesforce. The acceptance criteria describe a cart. The downstream catalog mapping belongs to a different system, owned by a different team, mentioned in no acceptance criterion at all.

Nobody skipped a step. The step was never in anyone's story.

The Single Habit Worth Building

After every order submit in a test run, open the Orchestration Plan and read the item list.

Not once per release. Every run. It takes under a minute, it is the difference between "the screen said yes" and "the system did it," and it is the cheapest habit in this entire discipline.

When your last order submitted successfully — did you open the plan, or did you trust the screen?