---
title: How to add a yes/no decision
url: https://tideswell.xyz/docs/workflows/add-a-decision
description: A condition compares something on the triggering record and sends the flow down the Yes path or the No path.
---

> Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further.

# How to add a yes/no decision



A **condition** compares something on the record that started the workflow and splits the flow
in two. It is what turns "when a repair is logged" into "when an **urgent** repair is logged".

## How do you add one? [#how-do-you-add-one]

From **Conditions** in the library, which offers comparisons grouped by the record type your
trigger uses. **Compare any field**, in the **Advanced** group, builds one from scratch with as
many rules as you need.

Connect your trigger's right-hand dot to the condition's left-hand dot.

## What are the Yes and No handles? [#what-are-the-yes-and-no-handles]

A condition has **two** outgoing dots: a green **Yes** and a red **No**.

Which dot your line leaves from decides which branch it is. Dragging out of the green dot builds
the path taken when the comparison matches, and the red one builds the path when it does not.

This is the most common mistake in the builder, and it is invisible once the lines are drawn.
When a workflow does the right thing at the wrong time, check which dot each line actually
starts from before you check anything else.

A connection leaving a condition from anywhere other than Yes or No is refused at publish.

## Do you have to use both branches? [#do-you-have-to-use-both-branches]

No. Most workflows use **Yes** only, and leave **No** unconnected, which simply ends the flow.

Use **No** when there is a genuine alternative. An urgent repair creates a task for the
warehouse lead on the Yes path, and a normal one notifies the team on the No path.

## What can you compare? [#what-can-you-compare]

Values on the triggering record: text, numbers, dates, choices from a list, checkboxes.

Fields that **link to another record** cannot be compared. The builder hides them rather than
offering something that would not work, and publishing refuses one if it gets in.

That means a workflow cannot branch on a task's assignee or department, which is worth knowing
before you design around it.

## Why did publishing refuse my condition? [#why-did-publishing-refuse-my-condition]

Three reasons, each named in plain English when it happens.

**A condition with no rules.** The message points out it would always take the Yes path, which
makes it a step that does nothing.

**A comparison or value left blank.** Half a rule is not a rule.

**A connection out of a condition that is not on Yes or No**, as above.

Each flagged step also shows its own red message on the canvas, so you can work down them. See
<Ref to="workflows/publish-and-read-a-run" />.

## How do you check the branch actually taken? [#how-do-you-check-the-branch-actually-taken]

The **Runs** tab reads a run as a story, and a condition's card says which way it went, for
example that it matched and carried on down the Yes path.

That is the fastest way to debug a workflow that runs but does the wrong thing. The run tells
you what the condition decided, and usually the answer is that the comparison was not what you
thought.

## Can you chain conditions? [#can-you-chain-conditions]

Yes. Connect a condition's Yes dot to another condition to require both.

For several rules about the same record, **Compare any field** with multiple rules is tidier
than a chain, and it is easier to read six months later.
