Triggers, conditions and branches

Every workflow is built from three kinds of logic. A trigger decides when it starts. Conditions decide whether it should keep going for a given record. And branches decide which actions run when one workflow needs to handle more than one case. Get these three right and the rest of the flow falls into place.

This guide explains each one as it actually works in KudosCRM — which events really fire a workflow, how AND/OR nested conditions and the operator set work, and how an N-way branch with an else path sends each run down the correct route.

Who this is for

People building or debugging workflows who want to understand exactly when a flow runs and how it decides where to go.

Before you start

• A workflow to work in (see "How to build your first workflow").
• A rough idea of the event you want to react to and the records you want to include or exclude.
• Familiarity with the fields you'll test in a condition (deal amount, lead country, stage, etc.).

Triggers that actually fire
Build on triggers that fire from real events: deals (created, updated, stage moved, won, lost), contacts and leads (created, updated, stage changed), forms (submitted), meetings (booked, completed, no-show, cancelled), quotes (sent, viewed, accepted, approved, expired), orders (placed), invoices (created), projects (created, status changed, milestone done, health degraded), campaigns (launched, clicked), and partners (lead registered, approved) — about 20+ in all. Scheduled (cron) and manual run-now triggers are on the roadmap, shown with a "Soon" pill.

How the three pieces work

1. Pick the trigger event
   The trigger is the event that starts a run. Choose one that matches the moment you care about — "deal stage moved" fires on every stage change, "deal won" fires only at the terminal win. The trigger also decides what data is available downstream: a deal trigger gives you the deal and its company; a form trigger gives you the submission.
2. Filter with a condition
   A condition is a test that must pass for the run to continue. For example: amount is greater than 10,000, or stage equals Proposal. If the condition fails, the run stops there — nothing after it executes for that record.
3. Combine tests with AND / OR
   Conditions support nested AND/OR groups, so you can express real rules: (amount > 10,000 AND owner is empty) OR (source is "Referral"). Group tests the way you'd say them out loud, and the builder evaluates the whole expression for each run.
4. Pick the right operator
   There are 13 operators to choose from — equals / not equals, greater than / less than, contains, is empty / is not empty, is in a list, and more. Match the operator to the field type: a numeric comparison for amount, "is in" for a set of countries, "is empty" to catch unassigned records.
5. Branch when one flow has many cases
   When the same trigger needs different handling, add a branch node. A branch can split N ways, each path with its own test, plus an else path that catches everything no path matched. High-value deals can take one route, mid-market another, and everything else the else path.
6. Put actions on each path
   Each branch holds its own actions, so the run only does what's right for the path it took. A deal on the "enterprise" path might post to Slack and assign a senior rep; the else path might just create a follow-up task.
7. Dry-run to confirm the route
   Before going live, dry-run a sample record. The simulator shows which condition passed and which branch the run took, so you can confirm the logic does what you meant — without sending anything for real.

What you get

• Workflows that start on the exact event you care about, not a vague one.
• Precise control over which records a flow runs for, using AND/OR and 13 operators.
• One workflow that handles several cases cleanly via N-way branches and an else path.
• Confidence the routing is correct, proven with a dry run.

Frequently asked questions

How many triggers are there, really?

More than 20, and they all fire from real events — across deals, contacts and leads, forms, meetings, quotes, orders, invoices, projects, campaigns, and partners. We don't pad the count: a few entries in the picker are placeholders for events that don't yet emit, so build on the documented ones above. Scheduled and manual triggers are on the roadmap.

What's the difference between a condition and a branch?

A condition is a gate — if it fails, the run stops. A branch is a fork — the run continues, but down one of several paths depending on which test matches, with an else path for the rest. Use a condition to decide whether a workflow should run at all; use a branch to handle multiple cases within one workflow.

Can I nest conditions with both AND and OR?

Yes. Conditions support nested AND/OR groups, so you can express compound rules like (A AND B) OR C. Combined with the 13 operators, that covers the great majority of "only run when…" logic without splitting a workflow in two.

What operators are available in a condition?

Thirteen, covering the common cases: equals and not-equals, greater-than and less-than, contains, is-empty and is-not-empty, is-in-a-list, and similar. Pick the operator that fits the field — numeric comparisons for amounts, "is in" for a set of values, "is empty" to find records missing a value.

What happens if no branch path matches?

The else path runs. Every branch has an else (catch-all) route, so a run is never stranded — if none of the explicit paths match, the run takes the else path and does whatever actions you put there. If you want unmatched runs to do nothing, simply leave the else path empty.

Learn more

• Workflows (feature) — The visual flow builder, triggers, and conditions on the feature page.