Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.docpipe.ai/llms.txt

Use this file to discover all available pages before exploring further.

DocPipe lets you branch a pipeline by setting conditions on edges. Every edge between two nodes has a condition that decides whether the edge fires when the source completes. By configuring those conditions, you can send a document down different paths based on its content, the previous step’s status, or a custom rule.

​
Edge condition types

Click any edge in the pipeline editor to open the properties panel on the right. The Condition Type selector controls when the edge fires:
TypeFires when
AlwaysThe source node completed (success or failure). Use this for unconditional flow.
On successThe source completed successfully. This is the default for new edges.
On failureThe source failed. Pair with On success to route errors to a separate handler.
ConditionA rule over the source node’s payload evaluates to true.
OtherwiseNone of the source’s other Condition edges fired. Use this as a fallback.

​
Authoring a Condition edge

When you pick Condition as the edge type, the properties panel shows a structured editor with three fields:
  • Field: the value to compare. Type {{ to autocomplete fields from the source node (for example, {{payload.invoiceType}}).
  • Operator: the comparison to apply. The dropdown filters operators by the inferred field type, so numeric operators stay hidden when the field is a string.
  • Value: the literal to compare against. Hidden for unary operators like is empty that don’t take a value.
Toggle Edit raw expression to edit the condition as a single expression string instead. This is useful for power users who want to copy and paste expressions or use less common syntax. Toggling back into the structured editor works as long as the raw expression uses the canonical operator set.

​
Operators

The structured editor surfaces these operators:
OperatorAliases (raw expression)Notes
==eq, equalsCase-insensitive string compare.
!=neq, not_equalsCase-insensitive string compare.
>gtNumeric when both sides parse as numbers, lexicographic otherwise.
<ltSame as above.
>=gteSame as above.
<=lteSame as above.
contains(none)Case-insensitive substring match.
not_containsnotcontainsInverse of contains.
is_emptyisemptyUnary. True when the field is missing, null, or an empty string.
is_not_emptyisnotemptyUnary. Inverse of is_empty.
Aliases work in raw-expression mode but always serialize to the canonical form when saved through the structured editor.

​
Inline popover on edge creation

When you connect two nodes by dragging an edge, an inline popover appears at the edge midpoint with five quick choices:
  • Always
  • On success (preselected)
  • On failure
  • If… (expands the structured editor inline so you can pick a field, operator, and value without leaving the canvas)
  • Otherwise
Press Esc, click outside the popover, or start a new canvas action to dismiss it. Dismissing keeps the preselected On success condition. You can always change the condition later by clicking the edge.

​
Branch from a node

To author multiple outgoing branches at once, click the branch action in any node’s hover toolbar. The Add branches modal opens with two rule rows by default:
  • Each row is a structured field, operator, and value.
  • Click Add branch to add more rows.
  • Tick Add an Otherwise edge for the fallback case to also create an Otherwise edge for inputs that match no rule.
When you click Create, DocPipe creates one outgoing edge per row plus the optional Otherwise edge. Each new edge is wired to a placeholder target that you can replace by clicking it and picking a real node from the search list.
Branches evaluate independently. If two rules can be true at the same time, both edges fire and the downstream paths run in parallel. Make rules mutually exclusive when you want exactly one path to fire.

​
Otherwise edges

An Otherwise edge fires only when none of the source node’s other Condition edges matched. The scheduler resolves Otherwise edges after evaluating siblings, so you don’t have to write a negation for every condition. A few rules:
  • A node can have at most one Otherwise edge. Saving a pipeline with two Otherwise edges from the same source raises a validation error.
  • Otherwise edges look at sibling Condition edges only. On success, On failure, and Always edges are independent and don’t suppress an Otherwise.
  • An Otherwise edge does not fire when the source failed. Use On failure for the failure path.

​
Example: route by document type

Parse Action
   ├── Condition: {{payload.invoiceType}} == 'B2B' → Extract (B2B schema)
   ├── Condition: {{payload.invoiceType}} == 'B2C' → Extract (B2C schema)
   └── Otherwise → Review queue
If the parsed type is B2B or B2C, only that branch fires. Anything else falls into the review queue.

​
Edge conditions vs route action

The Route action node and edge conditions both fan a run out into multiple paths but they answer different questions:
  • Edge conditions decide whether a single edge fires. Use them when you want a few branches with explicit rules and an optional fallback.
  • Route action groups, keeps, or drops items in a payload (for example, splitting an invoice with line items into one run per line). Use it when you need to fan out a single document into multiple downstream runs.
For most “if document is X, do Y” scenarios, edge conditions are the right tool.

​
Tips

  • Configure an Otherwise edge whenever you have a set of mutually exclusive conditions. Without one, runs that match no condition stop at the source node.
  • Keep conditions simple. If you need complex boolean logic, chain conditions through intermediate transform or validation nodes that produce a flag in the payload.
  • Test each branch with a representative document before activating the pipe.