Understanding task due dates

Last updated: July 2, 2026

Task due dates are relative, not scheduled: a task becomes due a set number of days after the moment it's created. There's no way to make a task due at a specific clock time like 8 AM — but you can control timing by controlling when the task is created.

What it is

Every form can carry a Due in (days) setting. When a task is created from that form — by a policy, a registration link, or the API — Onboarded stamps the due date by adding that number of days to the exact moment of creation. A task created at 3:42 PM with Due in (days) set to 3 is due at 3:42 PM three days later.

If you remember nothing else: the due date inherits the time of day the task was created. Due dates are anchored to creation, not to a calendar schedule.

Why it matters

Due dates drive how work gets prioritized — they're what your team sorts by in the dashboard, and what your reminder automations anchor to. The mental model matters most when:

  • You expect tasks to come due at a consistent clock time (say, every morning at 8 AM) and they don't.

  • You're building reminder automations and need to predict when a task actually becomes due.

  • A new form version ships and due dates on in-flight tasks shift unexpectedly.

How it works

Three ways a task gets a due date

  • From the form — the Due in (days) setting. Creation moment plus that many days.

  • From the dashboard — set or change a due date directly on a task.

  • From the API — pass an explicit due date when creating or updating a task. An explicit date wins over the form's setting.

A task with no Due in (days) and no explicit date has no due date at all — that's allowed, and common for evergreen tasks.

There's no clock-time scheduling. Onboarded can't make a task become due at 8 AM, or create a task at a scheduled time of day. If timing matters, control the creation moment instead — for example, create tasks through the API as part of a morning batch, so creation time (and therefore due time) lands where you want it.

What happens on a form version upgrade

When an in-flight task upgrades to a new version of its form, due dates that came from Due in (days) are recalculated against the new version's setting — measured from the task's original creation time. If the new version doesn't set Due in (days), the due date is cleared. Due dates you set explicitly from the dashboard or the API are left alone during upgrades.

Due dates aren't expirations

A due date is a target — an overdue task stays open and completable. Expiration is a separate mechanism that closes a task. If you want a nudge before either moment, see 📄 How do I send a reminder before a task expires?.

Example

Take an account that runs drug screens during pre-boarding. Its drug screen form sets Due in (days) to 3. A recruiter creates a placement at 3:42 PM on Tuesday, the policy assigns the task immediately, and the task is due at 3:42 PM on Friday.

The team wants every screening task due at the start of business instead. Rather than looking for a scheduling setting (there isn't one), they shift task creation: their integration creates the day's placements in an 8 AM batch, so every task lands with an 8 AM-anchored due date.

Read next