Connections with Conditions

A connection is the arrow between two nodes. It decides what runs next.

Left empty, it is always followed. Given a condition, it is followed only when that condition is met.

How a condition is built

Three parts:

• Value, what you are checking.
• Operator, how it should be compared. See Condition Operators and Field value.
• Output, what you are comparing it against. Some operators need two, such as Is between. Others need none, such as Is true.

You can also give the condition a Title and Subtitle. These have no effect on the flow, they are labels shown on the arrow in the editor. Use them, because a canvas of unlabelled arrows is unreadable a month later.

Picking a value

Both Value and Output have a picker, so you do not have to remember names. It offers four groups:

• Form Fields, the fields of the structure the lead came from.
• Keys, the tokens, endpoints and parameters the integration uses.
• System Parameters, values PalDock fills in itself.
• Previous Steps, everything produced earlier in the flow, including the parsed response body and the query of a previous request.

There is no separate Source setting. Where the value comes from is decided by what you pick, so a field from a response body is picked under Previous Steps rather than selected as “body” somewhere.

You can also type a value in directly, which is how you compare against a fixed string or number.

Example:

Value:    {parsedBody.status}
Operator: Equals
Output:   ok

This connection is followed when the response body contains a status field set to ok.

Several conditions on one connection

All of them must be true. There is no way to make them alternatives.

{status}             Equals   200
{parsedBody.valid}   Equals   true

This is followed only when the call succeeded and the service said the value is valid. Checking only the body is a common mistake, because an error response usually has no valid field at all, and the connection then behaves in ways you did not intend.

If you need alternatives, use two connections leading to the same node, each with its own condition.

Several connections from one node

Every connection whose condition is met is followed. That is how the flow branches: one node leads to three others, and the response decides which paths continue.

Two things follow from this:

• Make the conditions mutually exclusive, unless you want more than one branch to run. Two conditions that can both be true will both fire.
• Cover everything. If no connection matches, the flow stops there. Nothing is written, nothing is retried, and the run simply ends at that node.

The safest way to cover everything is to match the known outcomes explicitly and catch the rest with a negative match against them, rather than trying to list every value the other side might return.

Branching on a response

An advertiser returns a status and you want three outcomes:

Rejected:  {parsedBody.state}   Regex match       DEN|CAN
Approved:  {parsedBody.state}   Equals            APPROVED
Pending:   {parsedBody.state}   Regex not match   DEN|CAN|APPROVED

Anything new the advertiser starts returning lands in Pending, which is where you want it, rather than falling out of the flow.

Common mistakes

• Braces in the wrong place. Value takes a reference. Output takes what you compare against. Writing a field path into Output as plain text makes it a literal string that can never match.
• Relying on the status code alone. Most advertisers return a rejection with a perfectly normal 200.
• Leaving no path for the unexpected, so runs quietly end in the middle of the flow.
• Overlapping conditions on branches that were meant to be alternatives.