Conditional Runs
Outcome: every expensive column in your build wrapped in a condition, each tested on a sample, with the run cost recorded before and after.
- Surface
- App
- Level
- Intermediate
- Uses
- Conditional columns · filters
- Credits
- 0 to build; saves most of the run
- Prerequisite
- Lessons 05–08
What a conditional column does
A normal column runs on every row. A conditional column runs only where a condition is true — and where it is false, nothing runs and nothing is billed.
That is the entire mechanism, and it is the highest-leverage setting in an outbound build.
The five conditions worth having
Before contact enrichment
qualified = true AND role_matches = true AND NOT suppressed
The single biggest saving. Removes 60–80% of rows before your most expensive column.
Before research
qualified = true AND evidence IS NULL
Only research accounts you would actually contact, and only where cheap sources found nothing.
Before AI copy
email_status = "valid" AND evidence IS NOT NULL
Never generate copy for a row you cannot send to, or a row with nothing to say.
Before the personal-email fallback
work_email IS NULL AND eligible_for_personal = true
Fallbacks that run unconditionally stop being fallbacks.
Before phone lookup
score >= high_threshold OR segment = "local"
The most expensive column in the library needs the tightest condition.
The arithmetic
2,000 sourced companies, three contacts each.
Unconditional:
| Column | Rows | Cost | Total |
|---|---|---|---|
| Company enrich | 2,000 | 0.5 | 1,000 |
| Research | 2,000 | 1.5 | 3,000 |
| Find people | 6,000 | 0.3 | 1,800 |
| Email + verify | 6,000 | 1.1 | 6,600 |
| AI copy | 6,000 | 1.0 | 6,000 |
| 18,400 |
Conditional:
| Column | Rows | Cost | Total |
|---|---|---|---|
| Company enrich | 2,000 | 0.5 | 1,000 |
| Research (qualified only) | 600 | 1.5 | 900 |
| Find people (survivors) | 1,050 | 0.3 | 315 |
| Email + verify (role-matched) | 1,050 | 1.1 | 1,155 |
| AI copy (valid + evidence) | 800 | 1.0 | 800 |
| 4,170 |
77% cheaper, and the 800 people who receive a message are better qualified than any 800 of the unconditional 6,000.
Test the condition before you trust it
A condition reading a column that has not populated yet will either pass everything or fail everything, depending on how the comparison was written — and both look like a working pipeline.
Run on 20 rows
Count survivors by hand
Not from a summary — actually count.
Check both branches
Some rows must pass and some must fail. A condition that passes 100% or 0% is not doing anything.
Check null handling explicitly
What does your condition do when the column is empty? Test it with a deliberately blank row.
Null handling is where conditions silently break. evidence != "" and evidence IS NOT NULL behave differently on an empty column, and one of them will let every row through. Test with a blank row every time you write a condition, not just the first time.
Order matters as much as conditions
A condition placed after an expensive column saves nothing. Read your build top to bottom and confirm:
- Every free filter runs before every paid column
- Every cheap column runs before every expensive one
- Every expensive column has a condition directly above it
- Nothing company-level runs on the person table
Do this now
List every column with a cost
Write the condition for each
Using the five patterns above.
Test each on 20 rows
Count survivors by hand, check both branches, test the null case.
Reorder
Any expensive column above a cheap one moves down.
Compute both run costs
Conditional and unconditional, for your own row counts.
Run and compare actual consumption
Against the conditional estimate. A large gap means a condition is not firing.
Check your work
- Every paid column has a condition above it
- Each condition was tested on 20 rows with survivors counted
- Null behaviour was tested deliberately
- Column order is cheapest-first
- You have both cost numbers written down
Where this breaks
A condition that silently passes everything is worse than no condition, because it creates the belief that spending is controlled. The run costs what an unconditional run costs, the estimate said otherwise, and nobody investigates until the balance is empty. If a condition has never excluded a row, it has never been tested.
Further automation
Conditions are what make a scheduled run safe. A weekly job with proper conditions only pays for rows that newly qualified; the same job without them re-bills the entire table every week. Check consumption on the second and fourth run of any new schedule — that is when the difference becomes visible.
Next lesson
10 — Push to your sequencer, getting the finished list live.
Reference for this lesson: Actions, Tables, Credits, GTM Engineering — scoring and gating.