The most confusing workflow failures often look simple: an approval status says “approved,” yet the flow enters the missing-materials path; an amount is below the threshold, yet the next node is skipped. Looking only at the final node rarely reveals where the decision changed.
A condition branch usually follows four connected steps. An upstream node writes data into the variable pool. The condition node reads a selected path and evaluates one or more comparisons. The scheduler activates the edge associated with the selected case. Downstream nodes consume the resulting values. A reliable investigation follows the same order.
Illustration: four inspection layers from the input variable to the downstream output.
Start with the input variable
A condition node can only read values that have reached the variable pool. A renamed output field, an incorrect nested path, or a skipped upstream node can leave the branch with an empty value or an older value. Record the variable selector, the value observed at runtime, and the node that produced it. These three pieces should point to the same source.
In ZGI Workflow, node outputs are written back to the variable pool and later nodes read them through the node identifier and output field. That relationship is worth making explicit in a test sheet. Also keep types visible: the string 100 and the number 100 may take different paths when a comparison is evaluated.
Check the comparison and logical operator
Correct input data can still produce an unexpected branch when the comparison rule is wrong. Common causes include leading or trailing spaces, case differences, date formats, null handling, or using “equals” where the business rule requires “contains.” When several conditions are grouped together, verify whether the group uses AND or OR and whether the order of cases matches the intended rule.
ZGI’s condition branch reads the selected variable, evaluates the comparison operator, and records the condition results. Capture the actual value, expected value, and operator for every condition. This turns “it should have matched” into a result that another person can review.
| Layer | What to inspect | Typical clue | Next action |
|---|---|---|---|
| Input | Path, type, latest value | Empty, stale, or renamed field | Check the upstream node output |
| Condition | Operator, expected value, AND/OR | Format or whitespace mismatch | Run a fixed sample once |
| Branch | Selected handle and active edge | False path selected, node skipped | Compare the runtime record |
| Output | Downstream input and final value | Missing field or unchanged status | Check variable write-back and consumer |
Confirm the scheduler followed the selected edge
A true condition only identifies a selected case. The following nodes still depend on graph connections and upstream branch state. The scheduler continues along an active edge; a node without an active upstream path may be skipped. When the condition looks right but the result never appears, inspect the branch handle and edge connections before changing the rule.
Runtime records become more useful when viewed together: condition results, the selected handle, and node status should tell the same story. If the handle is correct, inspect the graph connection and downstream input. If the handle is wrong, return to the variable and comparison layers.
Reproduce the issue with a small sample set
Prepare three fixed cases: an obvious match, an obvious non-match, and a boundary value. Change one field at a time and record the input, condition result, selected branch, and downstream output. This keeps concurrency, stale variables, and external service changes from hiding the real cause.
For amounts, dates, and enumerated statuses, define one input format and one default value. When a model returns natural language such as “approved,” “passed,” or “review completed,” pass it through a structured step before the condition node. A branch should compare stable fields, not several phrasings that mean roughly the same thing.
Keep the diagnosis in the runtime record
Branch errors often return after a workflow is edited. Keep the test samples, expected paths, and observed results after each correction, then run the same checks before release. ZGI’s variable pool and runtime records give the team a shared place to discuss the input, decision, and execution result.
Stable branching comes from a visible chain: every input has a source, each condition can be reviewed, the active path is clear, and downstream nodes receive the expected fields. Working through these four layers makes troubleshooting easier to repeat and easier to turn into an acceptance checklist.
GitHub: https://github.com/zgiai/zgi
Gitee: https://gitee.com/zgiai/zgi
Top comments (0)