About Dynamic Schedule Using Event Time in Time Node
Imagine you have a thousand customers, each with a subscription that renews on a different date. You want to remind every single one of them seven days before their renewal — not seven days from now, but seven days before their date. With a standard scheduled send, that's a thousand manual campaigns. With the Event Time setting in the Time node, it's one flow.
You might wonder: why not just store the renewal date as a profile attribute and trigger off that? The problem is that most customers don't renew just once. They book again, renew again, register again — and every time they do, the new date overwrites the old one. A profile attribute can only hold one value at a time, so the moment a customer makes a second booking, the first date is gone. A custom event is different: each booking, each renewal, each registration fires a fresh event carrying its own date. The flow catches each one individually and schedules the right message for that specific date — without touching anything that came before.
Event Time reads that date directly from the event, then calculates exactly when each profile should receive the next message. One customer renews in three days, another in six weeks, a third just made their second booking while still waiting on the first: the flow handles all of them in parallel, automatically.
This is why it's sometimes called the Dynamic Scheduler — the timing isn't fixed. It moves with each person.
Note: This feature is in BETA. Reach out to your account manager to try it out.
Dynamic Schedule Using Event Time in Time Node
The Event Time setting in the Time node lets you calculate timing dynamically based on a date/time value from the triggering event. Instead of a fixed delay ("wait 3 days"), the node calculates when to release each profile based on their own event data — for example, "release 24 hours before their departure date" or "release 7 days before their renewal date."
This means every profile gets personalised timing. Two profiles entering the same flow will be released at different times if their event dates are different.
In this article
How dynamic scheduling works
A profile enters the flow via the Listen node, triggered by a custom event that contains a date/time field (e.g.
departure_date,renewal_date,webinar_date).
The profile reaches the Time node configured with Event Time.
The Time node reads the date/time value from the triggering event's data field.
It calculates the release moment based on your configuration — for example, "2 days before the departure_date value."
The profile waits in the Time node until that calculated moment, then moves to the next node.
Each profile's release time is calculated individually based on their own event data. Profile A with a departure on June 15 and Profile B with a departure on June 20 will be released at different times — even though they're in the same flow.
💡 Good to know - Event Time is the only Time node setting where the wait duration is different for each profile. Countdown, Specific Time, and Time Frame all apply the same timing to every profile.
Prerequisites
Before you can use Event Time, two things must be in place:
Prerequisite | Details |
Listen node configured with a Custom Event | The flow must be triggered by a custom event that you've set up via the Website Tracking tool or API. The Event Time setting reads data from this triggering event — it's not available for scheduled triggers or other event types. See Use Custom Events in Marketing Automation.  |
Custom event field with date or timestamp type | The custom event must include at least one field defined as a date or timestamp data type. This is the field the Time node will read to calculate the release time. Text fields containing date strings won't work — the field type must be explicitly set to date or timestamp when defining the custom event. See About Custom Events.
The field value is sent as a Unix timestamp (seconds or milliseconds) or an ISO date string (e.g.
|
⚠️ Important — Field type matters
The date/time field in your custom event must be defined as a date or timestamp type when you create the custom event schema. If the field is defined as a text/string type (even if it contains a date-like value such as "2026-06-15"), the Event Time setting won't recognise it. Verify the field type in your custom event definition before building the flow.
⚠️ Important: The date must be present in the event payload at the moment the profile enters the flow. If the field is missing or malformed, the profile cannot be scheduled and will exit via the Missed Deadline path.
Common use cases
Flight departure reminder
Custom event: "booking_created" with field departure_date. Time node: 24 hours before departure_date → Email: "Your flight departs tomorrow. Check in now!" Each passenger gets a reminder personalised to their specific departure.
Webinar reminder
Custom event: "webinar_registered" with field webinar_date. Time node: 2 days before webinar_date → Email: "Your webinar is in 2 days — add it to your calendar." Second Time node: 1 hour before webinar_date → SMS: "Starting in 1 hour — join here: [link]."
Subscription renewal reminder
Custom event: "subscription_created" with field renewal_date. Time node: 7 days before renewal_date → Email: "Your subscription renews in 7 days. Review your plan." Second Time node: 1 day before renewal_date → Email: "Renewing tomorrow — update your payment details if needed."
Appointment reminder
Custom event: "appointment_booked" with field appointment_time. Time node: 24 hours before appointment_time → SMS: "Reminder: your appointment is tomorrow at {{appointment_time}}. Reply YES to confirm."
Post-event follow-up
Custom event: "event_attended" with field event_date. Time node: 2 days after event_date → Email: "Thanks for attending! Here are the slides and a feedback survey." The "After" option lets you schedule messages after the date, not just before.
Setting up dynamic scheduling
Ensure the Listen node is configured to listen for a custom event that contains a date or timestamp field. See Prerequisites above.
Add a Time node to the canvas and click it to open the configuration panel.
Select "Event time" from the time setting options.
Choose "Event data" from the dropdown. Then select the specific date/timestamp field from the custom event (e.g.
departure_date,renewal_date).
Set the timing offset in the "When" section. Choose:
Before or After the event date
The duration: a number and unit (hours, days, weeks, months, or years)
For example: "2 days before departure_date":
Close the Time node and connect the next node (e.g. an Email node with the reminder content).
End with an End Flow node to close the path cleanly.
Date formats: timestamp vs. date string
The event data field can contain the date in two formats. Both are supported, but they behave slightly differently — and it is worth knowing which your system sends.
Unix timestamp
A Unix timestamp is a number representing the seconds (or milliseconds) elapsed since 1 January 1970 UTC. For example:
{ "renewal_date": 1756684800 } // seconds { "renewal_date": 1756684800000 } // millisecondsApsis One detects automatically whether the value is in seconds or milliseconds. Unix timestamps are always in UTC — the flow timezone setting determines how that date is interpreted for scheduling.
ISO date string
An ISO 8601 date string is a human-readable format. For example:
{ "renewal_date": "2026-09-01" } // date only { "renewal_date": "2026-09-01T10:00:00Z" } // date and time, UTC { "renewal_date": "2026-09-01T12:00:00+02:00" } // date and time, with timezone offsetIf you send a date-only value (no time component), the time is treated as midnight in the flow's configured timezone. If you send a datetime with timezone, that timezone is respected directly.
⚠️ Watch out for timezone mismatches: If your system sends a Unix timestamp (always UTC) but your flow is set to a different timezone, the scheduled send time will shift accordingly. For example, a timestamp representing midnight UTC will be treated as 2:00 AM in a flow set to Europe/Stockholm (UTC+2 in summer). Always align your event payload timezone with your flow timezone setting.
Which format should you use?
Format | Best when | Watch out for |
Unix timestamp (seconds) | Your platform natively exports timestamps; you need precise time-of-day scheduling | Always UTC — make sure flow timezone is set correctly |
Unix timestamp (milliseconds) | JavaScript-based systems (common in web and app platforms) | Same as above |
ISO date string (date only) | You only care about the date, not the time (e.g. a birthday) | Time defaults to midnight in the flow timezone — this affects the Before/On/After calculation |
ISO datetime string with timezone | Your system exports full datetimes and you want to preserve the local time | Verify that the timezone offset in the string matches what you expect |
💡 Tip: The format is validated against your custom event's field type definition. If the field is defined as a date type in the event schema, sending a Unix timestamp may be rejected. Check your event definition in Apsis One to confirm the expected field type before building the flow.
Understanding the two-layer configuration
The Event Time setting uses a two-layer configuration: a Condition and a When setting. Together, they define exactly when the profile should continue in the flow — and what happens if they miss the window.
Layer | What it controls |
Condition | Defines the type of timing rule: Before Time, In Time Range, Precisely On, or After Time. This determines the overall shape of the success window. |
When | Fine-tunes where the release point sits within the condition. Options are Before, After, or On (relative to the event date), plus a duration and unit (M/H/D/W/M/Y). |
The Summary Timeline
The UI shows a Summary Timeline that visualises the configuration. The timeline colours tell you what happens to the profile at each point in time:
Colour | Meaning |
🟢Green | Profile will continue — the profile advances to the next node in the flow. |
⬜Grey | Profile will wait — the profile stays in the Time node until the green success range is reached. |
🔴Red | Profile will exit the flow — the profile has missed the window and is removed from the flow. |
💡 Good to know — Not all conditions use all three colours
Before Time uses Green and Red (no grey — the profile either continues or exits).
In Time Range, Precisely On, and After Time use all three: Grey (waiting), Green (continue), and sometimes Red (exit).
Condition: Before Time
Before Time creates a success window that ends at the event date. Profiles that arrive during the green zone continue; profiles that arrive after the event date (red zone) exit the flow.
The When sub-option shifts how far before the event the success window extends:
When setting | What it means | Timeline |
Before + 1 Day | Profile continues if they reach the node more than 1 day before the event date. The success window ends 1 day before the event. Anything closer to the event → exits. | 🟢🟢🟢🟢⚫🔴🔴 — green ends well before the event |
On + 1 Day | Profile continues if they reach the node up to the event date itself. The standard "release 1 day before" use case — the green zone runs up to the event, then red. | 🟢🟢🟢🟢🟢🟢⚫🔴 — green extends right up to the event |
After + 1 Day | Profile continues if they reach the node up to 1 day after the event date. The success window extends slightly past the event. Gives a grace period for late arrivals. | 🟢🟢🟢🟢⚫🔴🔴🔴 — green zone is shorter, shifts earlier |
⚠️ Important — Before Time exits the flow on failure
Before Time is the only condition where profiles exit the flow entirely if they miss the window (red zone). The other conditions use grey (wait) instead. Use Before Time when it's critical that late profiles don't continue — for example, there's no point sending a flight check-in reminder after the flight has departed.
When to use Before — send X time before the event date
Use this when you want to reach the profile ahead of the event — for a reminder, a preparation message, or a heads-up. The profile enters the node immediately and is processed as soon as the flow reaches it, but the message is held until the calculated moment.
How the timing works: The profile is released at eventDate − offset. If the profile enters after the deadline has already passed, it exits via Missed Deadline immediately.
Use case: Subscription renewal reminder — 7 days before
A customer's subscription renews automatically. You want to remind them 7 days in advance so they can review their plan or update payment details.
Custom event field: renewal_date | Condition: Before | Offset: 7 days
Success window: Profile released exactly 7 days before renewal_date.
Missed Deadline: If the profile enters the flow less than 7 days before renewal, the deadline has passed. Connect a "last-minute reminder" branch from that exit.
Use case: Flight check-in reminder — 24 hours before departure
A travel booking platform sends a check-in reminder the day before each passenger's flight.
Custom event field: departure_date | Condition: Before | Offset: 1 day
Missed Deadline: Profiles added less than 24 hours before departure exit via Missed Deadline. Consider a fallback: "Your flight departs soon — check in now."
Use case: Webinar double reminder — 2 days and 1 hour before
Send two reminders by chaining two Time nodes with different offsets.
Custom event field: webinar_date
First Time node: Before | 2 days → Email reminder
Second Time node: Before | 1 hour → SMS "Starting in 1 hour"
Tip: Place a Check Profile node before the second Time node to filter out anyone who has unsubscribed.
Condition: In Time Range
In Time Range creates a success window with two boundaries — a Range Start and a Range End. Profiles inside the green window continue. Profiles arriving before the window (grey zone) wait until the window opens. Profiles arriving after the window closes (red zone) exit the flow.
This is the only condition with two separate configuration fields:
Field | What it controls |
Range Start | When the success window opens. Set with Before/After/On + duration. For example: "Before 1 Day" = the window opens 1 day before the event. |
Range End | When the success window closes. Set with Before/After/On + duration. For example: "After 1 Day" = the window closes 1 day after the event. |
Example: Range Start = Before 1 Day, Range End = After 1 Day
The success window is from 1 day before to 1 day after the event — a 2-day window centred on the event date.
Timeline: ⬜⬜⬜🟢🟢🟢⚫🟢🟢🟢🔴🔴 — grey (wait) → green (continue) → event dot → green (continue) → red (exit)
📸 Screenshot: In Time Range — Range Start: Before 1 Day, Range End: After 1 Day. Timeline shows grey → green → event dot → green → red.
⚠️ Validation rule — Range Start must come before Range End
The platform validates that the range is logical. If you set both Range Start and Range End to "After 1 Day" (the same point in time), you'll see the error: "Range start must be after range end." Make sure Range Start defines an earlier point in time than Range End.
Range — send any time within a window around the event date
Use this when flexibility matters more than precision — you want to reach the profile within a period rather than at an exact moment. The profile is released as soon as it enters the node, provided the window is open.
How the timing works: The window opens at eventDate + offset and closes at eventDate + rangeOffset. The profile is released when the flow reaches it, as long as the current moment falls within the window. If the window has not yet opened, the profile waits. If the window has already closed, it exits via Missed Deadline.
🗓️ Use case: Contract renewal outreach window — 30 to 7 days before
A B2B team wants to reach customers during a renewal engagement window — not too early, not too late.
Custom event field: contract_expiry | Condition: Range | Offset (start): 30 days before | Range Offset (end): 7 days before
Success window: Any time between contract_expiry − 30 days and contract_expiry − 7 days.
Missed Deadline: If the profile enters after the window has closed, it exits via Missed Deadline.
📬 Use case: Member anniversary re-engagement — 3 days either side
A membership club sends a loyalty offer any time in the week around each member's anniversary.
Custom event field: anniversary_date | Condition: Range | Offset (start): 3 days before | Range Offset (end): 3 days after
Condition: Precisely On
Precisely On creates a single-point success moment. Profiles wait (grey zone) until the configured moment, then continue (green zone turns to release). Profiles arriving after the moment has passed (red zone) exit the flow.
The When sub-option shifts where that precise moment falls:
When setting | What it means | Timeline |
On + 1 Day | Profile is released at the event date. Profiles arriving before wait (grey). Profiles arriving after exit (red). | ⬜⬜⬜🟢⚫🔴🔴🔴 — grey → event dot (release) → red |
After + 1 Day | Profile is released 1 day after the event date. Profiles arriving before that point wait (grey). Profiles arriving after exit (red). | ⬜⬜⚫⬜🟢🔴🔴🔴 — grey → event dot → more grey → release → red |
Before + 1 Day | Profile is released 1 day before the event date. Profiles arriving before that point wait (grey). Profiles arriving after exit (red). | ⬜⬜🟢⚫🔴🔴🔴🔴 — grey → release → event dot → red |
💡 Tip — Precisely On is a "single-point release"
Unlike Before Time (which has a wide green zone) or In Time Range (which has a window), Precisely On releases profiles at one specific moment. All profiles waiting in the node are released together when that moment arrives — making it useful for batch-style releases tied to an event date.
On — send on the event date (±5 minutes)
Use this when the message should go out at the moment the event date arrives — for a birthday greeting, an anniversary message, or a same-day notification.
How the timing works: The profile is released at eventDate + offset − 5 minutes and has until eventDate + offset + 5 minutes to be processed. This ±5 minute window is fixed and cannot be adjusted. If the flow does not process the profile within that 10-minute window, it exits via Missed Deadline.
⚠️ Narrow window: The On condition has a strict 10-minute success window. Make sure your flow does not have additional nodes that add processing delay before the send step.
🎂 Use case: Birthday greeting — on the birthday
Send a personalised birthday email on each member's birthday.
Custom event field: birthday | Condition: On | Offset: 0 days
Success window: Profile released at birthday − 5 min, must be sent by birthday + 5 min.
Important: This does not repeat automatically each year. See Annual recurrence below.
📅 Use case: Appointment confirmation — on the appointment date
A clinic sends a same-day message when a patient's appointment is today.
Custom event field: appointment_date | Condition: On | Offset: 0 days
Tip: For a reminder before the appointment, use the Before condition instead. Use On only when you want to send at the exact moment.
🏷️ Use case: Promotion notification — 2 hours into the offer start date
A promotion launches on a per-customer date, and you want to notify them 2 hours in.
Custom event field: offer_start | Condition: On | Offset: 2 hours
Success window: Profile released at offer_start + 2h − 5 min, deadline at offer_start + 2h + 5 min.
Condition: After Time
After Time creates a success window that starts at or after the event date and extends indefinitely forward. Profiles wait (grey) until the success window opens, then continue (green). There is no red zone — profiles never exit the flow with this condition.
The When sub-option shifts where the green zone starts:
When setting | What it means | Timeline |
On + 1 Day | Profile continues from the event date onwards. Profiles arriving before the event wait (grey). Once the event date passes, they continue. | ⬜⬜⬜⚫🟢🟢🟢🟢 — grey → event dot → all green |
Before + 1 Day | Profile continues from 1 day before the event onwards. The green zone starts earlier — giving a head start before the event date. | ⬜⬜🟢🟢⚫🟢🟢🟢 — grey → green starts → event dot → all green |
After + 1 Day | Profile continues from 1 day after the event onwards. Profiles wait past the event date and then 1 more day before continuing. | ⬜⬜⬜⚫⬜🟢🟢🟢 — grey → event dot → more grey → green starts |
💡 Good to know — After Time never exits profiles
After Time is the "safest" condition — profiles either wait (grey) or continue (green). There is no red zone, meaning no profiles are ever removed from the flow. Use this for post-event follow-ups where you always want the message to be sent, even if the profile enters the flow late.
After — send X time after the event date
Use this for follow-up messages that should go out after the event has passed — a post-event survey, a thank-you, a review request, or a next-steps guide.
How the timing works: The profile is released at eventDate + offset. There is no deadline for the After condition — the profile will always be released at the right moment, regardless of when it entered the flow.
💡 No missed deadline risk: Profiles that enter the flow late will still be released correctly once the offset time has elapsed from the event date.
⭐ Use case: Post-event survey — 2 days after
After a customer attends an event, send a satisfaction survey 2 days later.
Custom event field: event_date | Condition: After | Offset: 2 days
📦 Use case: Delivery follow-up — 5 days after shipment
Check in 5 days after a shipment date to ask if the order arrived and offer a review link.
Custom event field: shipment_date | Condition: After | Offset: 5 days
🔄 Use case: Onboarding check-in — 7 days after trial start
A SaaS product sends a check-in email one week after the trial start date stored in a custom event.
Custom event field: trial_start | Condition: After | Offset: 7 days
Timing options: Before, In Time Range, Precisely On, and After
The Condition dropdown determines the profile's release time relative to the event date. There are four options:
Condition | What it does | Example |
Before Time | Releases the profile a set duration before the event date. The most common option — for reminders and pre-event communication. | 24 hours before departure → reminder email. 7 days before renewal → heads-up email. |
In Time Range | Releases the profile when the current time falls within a defined window relative to the event date. Useful when you want to target a period around the event rather than a single point in time. Also covers late entries. | Between 48 and 24 hours before departure → send a check-in reminder. Between 1 and 3 days after purchase → send a review request. |
Precisely On | Releases the profile at the exact event date/time (zero offset). For messages that should be sent at the moment of the event. | At the renewal date → "Your subscription has renewed." At the event start time → "The webinar is starting now — join here." |
After Time | Releases the profile a set duration after the event date. For post-event follow-ups and delayed actions. | 2 days after the webinar → follow-up email with slides. 1 week after purchase → review request. |
Duration units available: minutes, hours, days, weeks, months, years.
💡 Tip — Multiple Time nodes for a reminder sequence
You can chain multiple Time nodes with Event Time to create a reminder sequence leading up to (and following) an event:
Time node 1: 7 days before→ Email: "Your event is in one week"
Time node 2: 1 day before→ Email: "Tomorrow! Here's what you need to know"
Time node 3: 1 hour before→ SMS: "Starting in 1 hour — join link: [link]"
Time node 4: 2 days after→ Email: "Thanks for attending — here's the recording"
All four Time nodes reference the same event date field — the offset just changes.
More about Condition (success window) and Time (offset)
The condition answers: how does the send time relate to the event date? The Time/offset answers: by how much? Together they define the exact moment a profile leaves the Time node and continues down the flow.
Think of the event date as a fixed point on a timeline. The condition tells the node which direction to look — before it, on it, after it, or across a span — and the offset sets the distance.
How the four conditions work — and how to choose
Condition | What it does | How offset applies | Deadline? | Think of it as… |
Before | Releases the profile at a point in time before the event date. The profile enters the node immediately but waits until the calculated moment. | Offset is subtracted from the event date. | Yes. If the deadline has already passed when the profile enters, it exits via Missed Deadline immediately. | "Send this message X time ahead of the event." |
On | Releases the profile at (or very close to) the event date itself. A fixed ±5 minute window is applied automatically — the profile is released 5 minutes early and must be processed within 10 minutes. | Offset shifts the target relative to the event date. | Yes — strict 10-minute window. Miss it and the profile exits via Missed Deadline. | "Send this message at the moment the event date arrives." |
After | Releases the profile at a point in time after the event date. No deadline — the profile will always be released correctly, regardless of when it entered the flow. | Offset is added to the event date. | No deadline. Profiles that enter the flow late will still wait until the correct time. | "Send this message X time following the event." |
Range | Defines a window with a start and an end. The profile is released as soon as the flow reaches it — provided the current moment falls within the window. If not yet open, the profile waits. If already closed, it exits via Missed Deadline. | Two offsets define the window: | Yes — at the end of the window ( | "Send this message any time within a period around the event." |
How condition and offset work together — concrete examples
The same event date with different conditions and offsets produces completely different send times. This table uses a single example — renewal_date: 2026-09-01 — to show the effect of each combination.
Condition | Offset | Calculated send time | What the profile receives |
Before | 30 days | 1 August 2026 | Early heads-up: "Your renewal is coming up next month." |
Before | 7 days | 25 August 2026 | Reminder: "Your subscription renews in one week." |
Before | 1 day | 31 August 2026 | Urgent nudge: "Renewing tomorrow — check your payment details." |
On | 0 days | 1 September 2026 ±5 min | Same-day message: "Your subscription has renewed today." |
After | 3 days | 4 September 2026 | Post-renewal check-in: "You're all set — here's your receipt." |
After | 14 days | 15 September 2026 | Mid-cycle check-in: "How is your subscription going so far?" |
Range | Start: −30 days / End: −7 days | Any time 1 Aug – 25 Aug 2026 | Sales outreach window: team contacts the customer any time during the period. |
Combining multiple Time nodes
You can chain several Time nodes in the same flow — each reading the same event date field but with a different condition or offset. This lets you build a full lifecycle of messages around a single event without creating separate flows.
A subscription renewal flow might look like this:
Time node 1 — Before, 30 days → Email: "Renewal coming up next month"
Time node 2 — Before, 7 days → Email: "One week to go — review your plan"
Time node 3 — Before, 1 day → SMS: "Renewing tomorrow"
Time node 4 — On, 0 days → Email: "You've been renewed — here's your confirmation"
Time node 5 — After, 3 days → Email: "Enjoying your subscription? Here's what's new"
Missed Deadline: what it means and how to use it
Every Time node configured with Event Time has a Missed Deadline exit. It happens when:
Profile enters the flow after the scheduled release time has already passed (e.g. a renewal reminder where the renewal date is tomorrow but the offset is 7 days).
Profile is not processed within the success window (most relevant for the On condition's narrow 10-minute window).
The event data field is missing or cannot be parsed as a date.
In the event node, monitor the "Left the flow" number as your "MIssed deadline profiles" will be sent down this path and exit the flow via the node.
Annual recurrence: birthdays and anniversaries
A common question is whether the Dynamic Scheduler automatically repeats each year for birthdays and anniversaries. It does not.
The Event Time mode reads the date value that was sent in the original custom event payload. If a profile's birthday is stored as 1990-07-20, the node uses that literal date — it will not shift to the next occurrence automatically.
To send a birthday or anniversary message each year, you need to re-trigger the flow annually. Common approaches:
Use a scheduled listener configured on the profile's birthday attribute to fire a custom event each year near the date.
Send a fresh custom event from your CRM or data platform each year, which re-enters the profile into the flow with the current year's date.
💡 Tip: If your use case is purely annual (e.g. a birthday email every year on the same date), discuss with your data team how to automate the annual event trigger from your CRM or CDP.
Date vs. Timestamp — how the field type affects behaviour
The custom event field you reference can be defined as either a date type or a timestamp type. This choice fundamentally affects how the Time node calculates the release moment.
Field type | What it stores | How the Time node uses it |
Date | A calendar date without a specific time. For example: | The Time node treats the date as midnight (00:00) in the flow's timezone. So "24 hours before" a date of June 15 = June 14 at 00:00. This means the time-of-day component is always midnight — you can't target a specific hour using a date field. |
Timestamp | A date plus a specific time. For example: | The Time node uses the exact date and time for its calculation. "24 hours before" a timestamp of June 15 at 14:30 = June 14 at 14:30. This gives you precise control over the release moment. |
💡 Which field type should I use?
Use timestamp when the time of day matters — flight departures, appointments, webinar start times, time-specific deadlines. This is the most common and most precise option.
Use date when only the calendar day matters — birthdays, renewal dates, anniversary milestones, expiry dates. The release will be calculated from midnight, which is fine when precision to the hour isn't needed. Combine with a Time node with Specific time or Time Range to avoid sending anything at midnight.
Example: Same offset, different field types
Condition: Before Time — 24 hours
Field type | Event value | Profile released at |
Timestamp |
| June 14, 14:30 — exactly 24 hours before the timestamp. |
Date |
| June 14, 00:00 — 24 hours before midnight on June 15. |
⚠️ Important — Timezone interaction with date fields
When using a date field, midnight is determined by the flow's timezone (set in Flow Settings). If your flow timezone is CET but your profiles expect messages based on their local time in a different timezone, the release may feel "off" by several hours. For time-sensitive communications, use timestamp fields and ensure the timestamp includes timezone information (or is sent in UTC).
All condition + field type combinations
Here's a complete reference showing how each of the four conditions behaves with both field types. All examples use an event value of June 15.
Before Time
Releases the profile a set duration before the event date/time.
Field type | Event value | Offset | Profile released at |
Timestamp |
| 24 hours | Jun 14, 14:30 |
Timestamp |
| 2 days | Jun 13, 14:30 |
Date |
| 24 hours | Jun 14, 00:00 |
Date |
| 2 days | Jun 13, 00:00 |
Use for: Reminders, pre-event communications, countdown-style notifications.
In Time Range
Releases the profile when the current time falls within a defined window relative to the event date/time. You set both a start and end boundary.
Field type | Event value | Range | Profile released when… |
Timestamp |
| 48h to 24h before | Anytime between Jun 13 14:30 and Jun 14 14:30 |
Timestamp |
| 1h to 3h after | Anytime between Jun 15 15:30 and Jun 15 17:30 |
Date |
| 48h to 24h before | Anytime between Jun 13 00:00 and Jun 14 00:00 |
Date |
| 1 to 3 days after | Anytime between Jun 16 00:00 and Jun 18 00:00 |
Use for: Flexible delivery windows ("send the reminder sometime during the 2 days before the event"), batch-processing around an event date, or when exact-to-the-hour timing isn't critical.
💡 Good to know — In Time Range behaviour
If a profile enters the Time node and the current time already falls within the range, the profile is released immediately.
If the current time is before the range, the profile waits until the range opens.
If the current time is after the range has closed, the range was missed — see Edge cases for how this is handled.
Precisely On
Releases the profile at the exact event date/time — zero offset.
Field type | Event value | Offset | Profile released at |
Timestamp |
| — | Jun 15, 14:30 exactly |
Date |
| — | Jun 15, 00:00 (midnight) |
Use for: Messages that should arrive at the exact moment — "Your subscription has just renewed", "The webinar is starting now", "Happy birthday!"
💡 Tip — Precisely On with date fields
When using Precisely On with a date field (no time component), the profile is released at midnight. If you don't want a midnight delivery, combine Precisely On with a subsequent Time Frame node to hold the profile until business hours. For example: Precisely On (birthday date at midnight) → Time Frame (release at 09:00) → Email (birthday offer).
After Time
Releases the profile a set duration after the event date/time.
Field type | Event value | Offset | Profile released at |
Timestamp |
| 2 days | Jun 17, 14:30 |
Timestamp |
| 1 hour | Jun 15, 15:30 |
Date |
| 2 days | Jun 17, 00:00 |
Date |
| 1 week | Jun 22, 00:00 |
Use for: Post-event follow-ups, delayed feedback requests, post-purchase sequences, "How was your experience?" messages.
Quick reference: Choosing the right combination
I want to… | Condition | Field type recommendation |
Send a reminder 24h before a flight/appointment | Before Time | Timestamp — time of day matters |
Send a heads-up 7 days before a renewal date | Before Time | Date is fine — only the day matters |
Send a reminder "sometime in the week before" an event | In Time Range | Either — depends on how precise the event time is |
Send a birthday email on the day | Precisely On | Date — then add a Time Frame node to control the hour |
Send a "webinar is starting now" SMS | Precisely On | Timestamp — exact start time needed |
Send a follow-up survey 2 days after an event | After Time | Timestamp if you want it at the same time of day; Date if any time is fine |
Send a review request 1 week after purchase | After Time | Either — combine with a Time Frame node if you want business-hours delivery |
Example walkthrough: Travel departure reminder
Let's walk through a complete example to show how all the pieces fit together.
Objective
Send a check-in reminder email to passengers 24 hours before their flight departure.
Prerequisites
A custom event called
booking_createdwith a fielddeparture_date(type: timestamp).Your booking system sends this event to Apsis One via the API when a passenger books a flight.
Flow setup
Listen node: Listen for → Custom Events → booking_created.
Time node: Event Time → Event data → departure_date → When: 24 hours before.
Email node: "Your flight departs tomorrow! Check in now." Personalised with event data (flight number, destination).
End Flow node.
What happens
Profile | Booking date | Departure date | Email sent |
Passenger A | 1 June | 15 June, 14:00 | 14 June, 14:00 (24h before) |
Passenger B | 3 June | 20 June, 09:00 | 19 June, 09:00 (24h before) |
Passenger C | 10 June | 12 June, 18:00 | 11 June, 18:00 (24h before) |
Each passenger gets a reminder at a different time — calculated individually from their own departure date. The flow handles this automatically, no matter how many passengers enter.
Edge cases and important behaviours
Dynamic scheduling introduces timing scenarios that don't exist with fixed delays. Here's what to expect in common edge cases:
Scenario | What happens |
The calculated release time is already in the past | If a profile enters the flow and the calculated release time has already passed (e.g. the departure is in 12 hours but the Time node is set to "24 hours before"), the profile moves to the next node immediately. The Time node won't hold them for a negative duration. |
The event date field is empty or missing | If the triggering event doesn't contain a value in the date/time field, the Time node cannot calculate a release time. Test this scenario to verify how the node handles it — the profile may be held indefinitely or may proceed immediately depending on the implementation. |
The event date is very far in the future | The profile will wait in the Time node until the calculated release time — even if that's months away. This is fine for use cases like annual renewal reminders, but be aware that profiles can accumulate in the node over time. Monitor Node Stats periodically. |
Multiple profiles with different dates | Each profile is released independently based on their own event data. The Time node handles many profiles with different dates simultaneously — there's no conflict or bottleneck. |
Flow is paused while profiles are waiting | Profiles remain in the Time node. When the flow resumes, profiles whose calculated release time has passed during the pause will advance immediately. Same behaviour as the Countdown time setting during pause. |
⚠️ Important — Test edge cases before activating
We strongly recommend testing the "date already passed" and "empty date field" scenarios with test profiles before activating the flow for production traffic. The behaviour in these cases can vary, and it's better to discover unexpected results during testing than with real customers.
Event Time vs. Countdown — what's the difference?
Both are Time node settings, but they calculate timing very differently:
Setting | How it calculates | Best for |
Countdown | Fixed duration from when the profile enters the node. Every profile waits the same amount of time. "Wait 3 days from now." | Spacing emails in a sequence, adding a fixed delay before a check, any scenario where the wait is the same for everyone. |
Event Time | Dynamic timing relative to a date/time value in the triggering event. Every profile's wait is different. "Release 24 hours before their event date." | Pre-event reminders, renewal notices, appointment reminders — any scenario where the timing depends on a date specific to each profile. |
💡 Quick test to decide Ask: "Is the timing the same for every profile?"
Yes (everyone waits 3 days) →Countdown.
No (each profile has their own target date) →Event Time.
Troubleshooting
Issue | What to check |
"Event time" option not available in the Time node | The Listen node must be configured with a Custom Event trigger. If the Listen node uses a different trigger type (scheduled, or a non-custom event), the Event Time option won't appear in the Time node. The field must be a date or timestamp. |
No date fields showing in the Event data dropdown | The custom event must have at least one field defined as date or timestamp type. If all fields are text/string/number types, no date fields will be available. Check the custom event definition and update the field type if needed. |
Profiles released immediately instead of waiting | The calculated release time is likely already in the past. For example, if a profile enters the flow with a departure date that's in 6 hours, but the Time node is set to "24 hours before", the release time was 18 hours ago — so the profile advances immediately. Check the event data values on the profiles. |
Profiles stuck in the Time node indefinitely | Check the event date value on the profile. If the date field is empty, malformed, or extremely far in the future, the profile may be held longer than expected. Also check that the flow is Active (not Paused). |
Timing seems off by several hours | Check the timezone in Flow Settings. The Time node uses the flow's timezone for calculations. If the timezone is set to UTC but your event dates are in CET, the release time will be offset. See Navigate the Canvas. |
Email sent at the wrong time | Verify the "Before/After" setting and the duration. "24 hours before" means the profile is released 24 hours before the date — the email is sent then (not 24 hours before the email send). Also check if there are other Time nodes between the Event Time node and the Email node that add additional delays. |
Tips & best practices
Verify the custom event field type. The most common setup issue is having the date field defined as a string/text instead of date/timestamp. Always check the custom event schema before building the flow.
Test with known dates. Before activating, create a test profile with a known event date (e.g. tomorrow) and verify the Time node releases them at the expected time. Check both the "before" and "past date" scenarios.
Chain multiple Event Time nodes for reminder sequences. One flow can have multiple Time nodes all referencing the same event date field with different offsets: 7 days before, 1 day before, 1 hour before, 2 days after. This creates a complete communication sequence around the event.
Consider what happens for late entries. If a profile enters the flow close to or after the event date, some or all of the reminder Time nodes will be in the past — and the profile will pass through them immediately. Decide if this is acceptable, or add a Check Profile node to filter out profiles whose event date has already passed.
Use Event Time for dates, Countdown for spacing. In a single flow, you might use Event Time to position the first message relative to the event date, then Countdown to space follow-up messages after that first message. They work well together.
Monitor Node Stats for accumulation. If your event dates are far in the future (e.g. annual renewals), profiles can accumulate in the Time node for months. This is normal, but check Node Stats periodically to verify profiles are being released on schedule.
Document the event field mapping. In the Goals section of the flow, note which custom event and which field the Time node is referencing. For example: "Time node reads departure_date from custom event booking_created." This helps colleagues understand the flow without opening the Time node configuration.
Account for timezone differences. If your audience spans multiple timezones but your flow uses a single timezone setting, some profiles may receive reminders at unexpected local times. For timezone-sensitive communications (like appointment reminders), consider whether the event date includes timezone information.
Related articles
Time Node — All four time settings: Countdown, Specific Time, Time Frame, and Event Time.
Use Custom Events in Marketing Automation — How to create and send custom events with date fields.
About Custom Events — Custom event schema and field types.
Listen Node — Configuring the Listen node with a custom event trigger.
Email Node — Sending the reminder email after the Time node releases the profile.
SMS Node — Sending an SMS reminder for time-sensitive notifications.
Check Profile Node — Filtering out profiles with past event dates.
Navigate the Canvas — Flow settings including timezone configuration.
Key Terms Glossary — Definitions for all Marketing Automation terms.