Lesson 2.1.7
Let a column finish before the next one reads it
What this costs
Free. This is a sequencing habit, not a tool.
Before you start
Any workflow where one column reads another.
Columns run asynchronously. If you create a column that reads another column while that one is still filling, the reader sees blanks and treats them as answers. Nothing errors. You get a quietly wrong result and no indication that anything went wrong, which makes this the hardest failure in the product to spot.
What actually happens
You create a Website column across 600 rows. It starts filling. Two minutes later you create a people column that depends on it and hit run. At that moment maybe 200 rows have a website. The people column reads the table as it is now: 200 rows with an input, 400 without. It skips the 400. Fifteen minutes later the website column finishes, all 600 rows have a domain, and the people column has already made its decisions.
- 1
Build the stack in dependency order and let each finish
Websites, then qualifiers, then scoring, then people. Watch each column complete before creating the one that reads it. On a large table that is a genuine wait, and it is cheaper than the alternative.
- 2
Check the completion state, not the visible rows
The rows on screen are not the whole table. Confirm the column has finished across all rows rather than across the ones you can see.
- 3
When you cannot wait, gate on the input explicitly
Set a condition on the child column requiring the parent field to be non empty. Rows that were not ready are then skipped rather than wrongly processed, and a skip is recoverable where a wrong answer is not.
- 4
Re run only the rows that were not ready
Once the parent has finished, filter to the rows the child skipped and run it on those. Successfully enriched rows are not re processed, so you do not pay twice for the ones that worked.
Created a dependent column while the parent was still running
- What you see
- Coverage far below what the same workflow produced last time, with no error anywhere
- The fix
- Wait for the parent. If you cannot, gate the child on the parent field being non empty.
Judged completion from the visible rows
- What you see
- The first hundred rows look finished, the last four hundred are not
- The fix
- Check the column state across the whole table.
Re ran the whole child column to fix it
- What you see
- Paying again for rows that already succeeded
- The fix
- Filter to the skipped rows and run on those only.
A scheduled refresh recreated the race
- What you see
- The workflow degrades on its own over time
- The fix
- Conditions travel with the column, so gate the dependency explicitly rather than relying on timing. Course 3.1 covers scheduling properly.
You have finished the expensive part
Website first, conditions on everything, a waterfall where it pays, a custom column with a forced format, validation only where being wrong is costly, and a diagnosis for every blank. That is the whole cost discipline. Next comes making the cut defensible, which is scoring.
Check yourself
0 of 2 answered1.You create a column that reads another column while that one is still filling. What happens?
2.If you cannot wait for the parent column to finish, what should you do?
Try it yourself
Take a two column dependency you already have. Add an explicit condition on the child requiring the parent field to be non empty. Run it, then check how many rows were skipped rather than wrongly processed.
- You have done it when
- Zero rows in the child column processed without a parent value.
- Credit budget
- Free to configure.