Conditions And Branches

Conditions and Branches

Workflows aren't just a flat list of actions — you can add logic with two special step types: Conditions (only continue if X is true) and Branches (split the workflow into multiple paths and walk down the first one that matches).

Which one do I want?

Use a Condition step when…	Use a Branches step when…
You want some steps to run only when a condition is met.	You want different steps to run depending on which case matches (like an if/else if/else).
"Only send the email if the customer opted in."	"If status is New, do A. If Approved, do B. Otherwise, do C."
One yes/no decision in the middle of the workflow.	2+ mutually exclusive paths.

Condition steps

A Condition step holds a group of conditions. The steps that come after it only run if the conditions evaluate to true. If the conditions are false, those later steps are skipped.

Configuring a condition

Each condition has three parts:

1. Left side — what to check. Usually a field on the source record, but it can also be a value from a previous step, the logged-in user, or an app variable.
2. Operator — how to compare.
3. Right side — what to compare against. A static value, another field, a previous step's response, or the logged-in user.

Available operators

Operator	What it checks
is	Exact match.
is not	Anything except an exact match.
contains	String contains the substring (case-insensitive).
does not contain	String doesn't contain the substring.
starts with	String begins with…
ends with	String ends with…
is blank	Field is empty / null.
is not blank	Field has any value.
higher than	Numeric / date comparison.
higher than or equal to	Numeric / date comparison.
lower than	Numeric / date comparison.
lower than or equal to	Numeric / date comparison.

Combining conditions with AND / OR

You can stack multiple conditions in the same group, joining them with AND or OR. Conditions can be nested into sub-groups for more complex logic.

Example — AND: Send the reminder email only when Status = Sent AND Due Date is before today.

Example — OR: Notify the manager when Priority = High OR Total > 10000.

A complete example

1. Trigger: Record Created on Orders.
2. Step 1: Send Email — order confirmation to customer.
3. Step 2: Condition — Total > 1000.
4. Step 3: Slack: Send Channel Message — alert the sales team about the big order. (Skipped if the condition is false.)
5. Step 4: Update Record — set VIP Order = Yes. (Also skipped if the condition is false.)

Steps 3 and 4 only run when the order is over $1,000. Step 1 always runs because it's before the condition.

Branches steps

A Branches step splits the workflow into multiple lettered paths (A, B, C, …). Tadabase walks the branches in order and runs the steps in the first branch whose conditions evaluate to true. The other branches are skipped.

Anatomy of a Branches step

• Each branch has a label (you can name them — e.g. "VIP," "Standard," "Free").
• Each branch has its own condition group, configured the same way as a Condition step.
• Each branch has its own list of action steps that run if the branch is selected.
• An optional default branch (no conditions) catches anything that doesn't match earlier branches — it's like an "else."

Branches vs. multiple Condition steps

You could implement an "if/else if/else" with three Condition steps in a row, but the result would be subtly wrong — multiple Conditions are independent gates, not mutually exclusive. Branches is the right tool when only one path should run.

A complete example

Goal: When a Lead is created, route it to a different team based on the deal size.

1. Trigger: Record Created on Leads.
2. Step 1: Branches.
   • Branch A — Enterprise: Estimated Value > 50000.
     • Update Record: Assigned Team = Enterprise.
     • Send Email to enterprise@example.com.
   • Branch B — Mid-market: Estimated Value > 5000.
     • Update Record: Assigned Team = Mid-market.
     • Slack: post to #midmarket.
   • Branch C — Default (SMB): no conditions.
     • Update Record: Assigned Team = SMB.
3. Step 2: Send Email — welcome message to the lead. (Always runs after the Branches step finishes.)

An order with Estimated Value = $75,000 hits Branch A. An order with $10,000 hits Branch B. Anything below $5,000 falls through to Branch C. Step 2 always runs once whatever branch was chosen has finished.

Conditions on the trigger vs. inside the workflow

Trigger Filters (on the Trigger card) and Condition steps (inside the workflow) both let you filter what happens, but they fire at different points:

• Trigger Filters — applied before the workflow runs. If the filter doesn't match, the workflow doesn't run at all and nothing is logged.
• Condition steps — applied inside the workflow. The workflow always runs and is logged in History; some steps are skipped depending on the condition.

Use Trigger Filters when you want to keep noise out of History entirely. Use Condition steps when you want a record of every run plus visibility into which branches fired.

Tips for conditions and branches

• Name your branches. A branch labeled "VIP" is much easier to read in History than "Branch A."
• Always include a default branch if you want a fallback path. Without one, Branches that don't match any condition simply skip everything.
• Test both true and false paths. Use Dry Run with sample data so you can verify each branch fires when you expect.
• Watch the operator semantics — "is blank" versus an empty string can behave differently for some field types. When in doubt, run a quick test.