Por mariogarcia The failure that doesn’t look like one
A daily orchestration queried inventory to generate replenishment orders whenever stock dropped below the safety level. One day, the query filter fell out of sync with a change in the item master, and the query started returning zero rows. The orchestration didn’t fail — there was simply nothing to process, so it finished green, same as any day with no pending replenishments. Except there were pending replenishments. Nobody noticed until a warehouse ran out of a critical item almost a week later. 
Why Orchestrator doesn’t flag this as an error by design
A data request returning zero rows is, to the engine, a valid outcome — not an exception. The real business rule (“zero rows here means something’s wrong”) lives in the head of whoever designed the process, not in the framework. If that rule never gets translated into an explicit validation, the system has no way to tell “nothing to do” apart from “something broke before it got here.”
The first piece: errors that already tell you where to look
Since the May 2024 Tool Release, when a real exception occurs in a Form Request, the detail includes the field name, the data item alias, and the table the value lives in — and for grid errors, the exact row number. The Simple Message Error variable turns that into a clean message for the end user, without exposing raw technical detail. That solves half the problem: when something actually fails, diagnosis is immediate. It doesn’t solve the case of a query that “works” and returns an empty result that shouldn’t be possible.
The second piece: making the business assumption explicit
For that case, a Logic Extension was added right after the inventory data request: if the returned row count is zero, instead of letting the process continue silently, it raises a business error through a BSFN call, with a specific message — “no items found below the safety stock level for the given selection” — instead of a generic “0 rows returned” that nobody would read as an alarm. The difference isn’t cosmetic: an explicit business error triggers a notification, shows up in the message center, and gets reviewed the same day. A silent empty result triggers nothing.
Measurable impact
Since this validation went into the critical replenishment and invoicing processes, the average time to catch a configuration failure went from “days, whenever someone notices the consequence” to “minutes, when the notification lands.” It’s not an exotic feature — it’s a validation step that takes minutes to build and decides whether a problem gets caught before or after it hits the business. How many of your automated processes assume “no result” always means “all good”?