Formula Writing Rules
Rules for branch return types, plain-language breakdowns, variable naming, empty-value checks, and layered formula design.
Use this page when organizing complex formulas. Read it before writing long formulas so debugging and maintenance do not become painful later.
Keep branch return types as consistent as possible
Not recommended:
Recommended:
Or:
Return types need to be especially strict in automations, button variables, and date-field filling.
Write complex formulas in plain language first
For example, write "project health" as:
- Get all tasks.
- Count completed tasks.
- Count overdue unfinished tasks.
- Calculate completion rate and overdue rate.
- Output a color label based on the score.
Then translate it into:
Name variables by business meaning
Not recommended:
Recommended:
Check empty values before calculating
For dates, relations, people, and number inputs, first consider whether the value may be empty.
Design large formulas in layers
For template systems, it is better to separate formulas into three types:
| Type | Purpose | Displayed? |
|---|---|---|
| Raw input | Data manually filled in by the user | Displayed |
| Intermediate metrics | Helper calculations, such as completed count, overdue count, or remaining days | Can be hidden |
| Display result | Statuses, labels, or progress bars shown to the user | Displayed |
If all logic is packed into one formula, it may look tidy in the short term, but it becomes much harder to maintain over time.
To use these formulas directly in task reminders, project progress, note heatmaps, and reports, continue with FLO.W Notion Template.
Last updated on
Relation Statistics Formulas
Use Notion formulas to work with relation properties, replace parts of rollups, calculate multi-level relations, and summarize projects.
Common Errors and Troubleshooting
Troubleshoot type mismatches, empty dates, list-versus-single-value mistakes, dateBetween offsets, and regex escaping errors in Notion formulas.
Notion Formulas