Notion Formula Date Errors: Fix Date, Text, List and Empty Inputs

dateAdd needs a Date as its first input. A date that has passed through formatDate is Text, and a relation or rollup can supply a List. Check the value entering the function, then keep it as a Date through the calculation. In an automation that edits a Date property, the formula’s return type matters too.

I’d start with the input type before changing the deadline rule. A formula can display a convincing date and still hand the wrong type to the next function. The patterns below follow Notion’s documented syntax, and the property names are placeholders for your own database.

Locate the error before editing

First, identify the formula’s destination. A database Formula property displays its own result. An automation formula supplies a value to an action, such as setting a Date property. Notion’s automation return-type guidance explains that the action expects a specific type, so a formula accepted as a database property may still be unsuitable for that action.

Copy the existing formula into a note before changing it. Then open the editor from a row that has the problem. Notion documents a live preview for the selected database row, which helps you inspect the failing input instead of relying on a different row with a populated date.

For a nested formula, read from the inside out. Write down the type returned by the innermost expression, then compare it with the next function’s input. Notion’s property and formula type reference distinguishes Date properties from Text and lists; the way a value looks on the page does not change that type.

Calculate before formatting

For a populated Date property named Due date, this pattern adds seven days and keeps the result as a Date:

dateAdd(prop("Due date"), 7, "days")

The inputs have separate roles: a Date to start from, a Number to add, and a supported unit string. Keep a variable offset in a Number property. Quoted "7" is Text; it is not the same input as the number 7. The documented date functions include "days" as a supported unit.

Use formatDate at the end when you need a text label:

formatDate(
  dateAdd(prop("Due date"), 7, "days"),
  "YYYY-MM-DD"
)

This second expression produces Text. The formatDate examples show quoted text results, while dateAdd returns a date. Passing the formatted result back into dateAdd creates the wrong input type. For an automation that writes a Date property, keep the first pattern’s Date result.

Avoid this nested expression when Due date is a Date property:

dateAdd(formatDate(prop("Due date"), "YYYY-MM-DD"), 7, "days")

Read it from the middle: Due date supplies a Date, but formatDate turns that value into Text before dateAdd receives it. Moving the formatter outside the calculation fixes that type path. Take a date-only input of October 11, 2026: the intended Date result is October 18, and formatting that result as YYYY-MM-DD gives you the label 2026-10-18.

Parse a controlled text date

If the source is Text, parseDate uses the ISO 8601 standard to convert it to a Date. A populated text property containing an ISO date such as 2026-10-11 works as the input for this pattern:

dateAdd(parseDate(prop("Due date text")), 7, "days")

The conversion happens before the calculation. It depends on the source being a valid ISO date, so do not use this as a general parser for next Friday or inconsistent human-entered formats. I recommend a Date property when a teammate can select the date directly. That removes a text-conversion step from the deadline calculation.

Resolve related dates with an explicit rule

A Relation supplies a list of pages. A Rollup can return a Number, Date, or List depending on its configuration, as Notion’s formula type table specifies. One visible related item does not make a list into a single Date.

For example, this expression maps related project pages to their Due date values:

prop("Projects").map(current.prop("Due date"))

map returns a List. Adding .first() selects its first item; it does not establish an earliest-date rule. Use that selection only when the first item is the date you intend to use, and account for an empty relation or a related page without a date.

For a project deadline based on related tasks, I prefer to state the rule in the rollup configuration. Notion provides Earliest date, Latest date, and Date range calculations for Date properties. Choose Earliest date when the earliest related deadline should drive the result, or Latest date when the final related deadline should drive it. These calculations use the related pages; choosing Earliest date does not itself exclude completed tasks. If you choose Date range, use dateStart or dateEnd to select the required endpoint before the next calculation.

Suppose the related values you are considering are October 18 and October 11. Selecting the first listed value would choose October 18 in that example; an Earliest date rule chooses October 11. The two answers are both dates, so a type check alone cannot tell you which deadline your workflow needs. Write down the selection rule before replacing a List with a single item.

Check other formulas that use the rollup before changing its calculation. If the rollup itself is unexpectedly empty, follow the relation, source-property, and access checks for an empty rollup first. Converting its output cannot supply a missing source date.

Handle an empty date according to the destination

Start by deciding the intended behavior on a blank source. Should the result stay blank, display a label, leave an existing target date alone, or clear that target date? Those are different outcomes.

For a database Formula intended to display Text, both branches can return Text:

if(
  empty(prop("Due date")),
  "",
  formatDate(dateAdd(prop("Due date"), 7, "days"), "YYYY-MM-DD")
)

This pattern skips the calculation on a blank source and formats the populated branch as a label. It is a Text output, so it does not provide a Date for a Date destination.

For a database Formula intended to retain a blank Date source, the following pattern returns the source property in the empty branch and calls dateAdd only in the populated branch:

if(
  empty(prop("Due date")),
  prop("Due date"),
  dateAdd(prop("Due date"), 7, "days")
)

The pattern follows the documented if, empty(value), and Date-property types. Check its return type in your editor on a blank row as well as a populated row before using it downstream. The empty(value) predicate checks for an empty input; it is distinct from the zero-argument automation example below.

Match an automation’s Date output

Notion’s wrong-return-type example explains why if(Date, Date.dateAdd(1, "day"), "") is unsuitable for a Date action: one branch returns Date, and the other returns Text. Its documented replacement uses empty().

That replacement has a consequence you should choose deliberately: when the source date is absent, it clears the property being updated. In Notion’s example, Date represents the source date value selected in the automation editor:

if(Date, Date.dateAdd(1, "day"), empty())

Use this documented automation pattern only when clearing the target is the intended blank-source behavior. If blank inputs should leave an existing target date alone, Notion’s automation error guidance offers another route: create a view that excludes empty source dates and configure the automation to run on that view. Check that its other filters still include every relevant page.

Don’t stop at a populated source; inspect a populated target too. Take a row where the target deadline already holds October 20 while the source date is empty. The documented empty() branch clears that target. A view that excludes the blank source keeps this automation off the row, so its October 20 deadline stays put. Keep other automations out of that comparison, since they could still change the target independently.

Check that you have access to every referenced database and page. If the error specifically reports the formula depth limit, Notion documents a maximum of 15 layers of formula and rollup references; simplify the dependency chain rather than adding another conversion.

If an error paused the automation, turn it back on once the formula is fixed. Open its automation menu and toggle Active on, following the documented recovery steps. Fixing the formula alone doesn’t resume it.

Check a wrong date after the type is correct

A valid Date result can still come from the wrong property or implement the wrong deadline rule. Confirm the actual source token first, particularly when several properties have similar names. In a reported Make integration case, the author identified an incorrectly selected property value among the errors. That is a useful mapping check, not evidence that all Notion date problems have the same cause.

Next, inspect any date range and choose its intended start or end. Check whether the rule needs a calendar date or the current time: Notion defines today() as the current date without time, and now() as the current date and time. Its ISO parsing examples also distinguish a date-only string from a timestamp containing a time and Z UTC marker. Keep that distinction when a value crosses into an integration.

If the remaining problem is a dateBetween count, use the dateBetween off-by-one guide to check argument order and the date rule. Changing a Date to Text doesn’t fix a count that follows the wrong rule.

Before applying the revised formula to a deadline workflow, inspect a populated source and a blank source. For related dates, include rows with no related page, one page, and several pages. Confirm the intended output type and the blank-source behavior; for an automation, check whether an existing target date should survive or be cleared.