invoice_number
total_amount
bill_to_name
due_date
→
invoice_number
total_amount
NodesCredits60 per pageYou get
The workflow
The condition names a field from the Extract node above it, an operator, and a value. The edge that leaves the If/Else node carries"branch": "true" or "branch": "false".
client.workflow(...).parse().extract(...)) has no if_else() verb either. Build a WorkflowDefinition from the node classes, as above.
Response
A run does not tell you which branch it took. There is no branch field anywhere in the envelope. You read the outcome from what ran: an invoice over the limit comes back with two entries inextractions, one per Extract node; the same invoice under the limit comes back with one, because the node on the True branch never ran.
Tell someone about it
An extra Extract node is a placeholder for whatever the branch should do. The usual end of a True branch is a Slack alert: a message in the channel that owns the decision, with the extracted values in it.When it goes wrong
Every document takes the True branch. The comparison reads the field as a number only when the field is a number.total_amount declared as a string compares as text, where "900" is greater than "4000". Declare amounts as float.
Nothing takes either branch. The condition names a field that the Extract node above it does not produce. left is the field name, spelled exactly as in the schema.
You cannot tell what happened. Add the alert, or give the False branch its own node too, so each path leaves a trace. Reading the branch from the count of extractions is fine in a script and painful in an audit.
You want more than one test. One If/Else node holds one condition. Chain a second node on the branch of the first for “over the limit and from a new supplier”.
Next steps
If/Else
Every operator, and conditions on a validation result
Slack alert
The message template, its placeholders and the severity

