Dynamic trigger timers allow a journey step to activate based on a date or date and time stored on the individual profile, rather than a fixed delay that applies equally to everyone. Each profile progresses through the journey according to its own date value, such as a contract end date, a departure date, or a renewal date.
Use dynamic trigger timers when:
The timing of an action depends on a date that varies per customer (for example, subscription expiry, flight departure, or policy renewal).
You want to activate a step a specific number of days before or after a profile-level date.
A fixed delay would not work because each profile has a different relevant date.
How dynamic trigger timers work
A dynamic trigger timer reads a date value from a profile variable, parses it using a specified date format, and creates a time gate that holds the profile until the condition is met. The orchestration engine evaluates the trigger when new events arrive for the profile, and lets the profile through once the configured time condition becomes true.
Example flow:
A profile enters a journey and a date value is captured into a profile variable (for example, `departureDate` from a flight search event).
A subsequent trigger is configured with a dynamic trigger timer rule that references that variable.
The engine parses the variable value using the configured date format and calculates when the time condition will be satisfied.
The profile is held at the trigger until the condition is met. Once the calculated time arrives, the engine releases the profile to the next step.
If a new event arrives that updates the variable value (such as when the customer rebooks to a different date), the engine recalculates the time gate based on the new value.
Understanding the time trigger conditions
The dynamic trigger timer condition consists of the match type and time frame.
The match type defines if the trigger fires before or after the event
The time frame defines when, in relation to the date, the trigger fires.
Read the time trigger conditions together as a sentence:
Before, In the future: The date is less than X away in the future. Use this to trigger before the date arrives.
After, In the past: The date is more than X ago in the past. Use this to trigger after the date has passed.
Before, In the past: The date is less than X ago in the past. Use this to trigger within a window after the date has passed.
After, In the future: The date is more than X away in the future. Use this to trigger while the date is still far away.
See the following example scenarios:
Scenario | Match type | Time frame | Period | What it means |
|---|---|---|---|---|
Trigger 2 days before departure | Before | In the future | 2 days | Fires when the departure date is less than 2 days away |
Trigger 3 days after contract end | After | In the past | 3 days | Fires when the contract end date was more than 3 days ago |
Trigger on the renewal date | After | In the past | 0 days | Fires once the renewal date has passed |
Combining dynamic trigger timers
Dynamic trigger timers can be combined with other rule types using AND/OR logic.
For example, you can combine a dynamic trigger timer with an engagement rule so that a profile only advances when both the time condition is met and a specific event has occurred.
When using dynamic trigger timers on flexible transitions (OR conditions), they must be combined with at least one rule that is not a dynamic timer trigger, external fact, or AI fact. This constraint prevents evaluation loops. Rules such as engagement, conversion, or visit satisfy this requirement.
Time triggers can also be used as goals in a journey to automatically remove profiles after some time. This can be useful when there is no event available for exit/conversion and exit conditions can't be easily configured, such as service-oriented use cases.
Comparison with fixed trigger timers
See below the key differences between fixed trigger timers and dynamic trigger timers to help you select the right rule for your journey.
Fixed trigger timer | Dynamic trigger timer | |
|---|---|---|
Timing | Same delay for every profile | Different time for each profile based on its data |
Input | A static duration (for example, 30 days) | A date value stored in a profile variable |
Use-case | Wait 7 days after entry, then send a reminder | Send a reminder 2 days before each customer's contract end date |
Recalculation | Not applicable | Recalculates when the variable value is updated by a new event |
Before you begin
Before a dynamic trigger timer can evaluate a profile, the profile must have a date value stored in a variable. This is done through variable mappings on an earlier step's trigger rules.
For example, if your journey starts with a "Flight Search" engagement, map the departureDate event property to a journey variable called departureDateVariable. The variable type must be String.
Make sure the following are in place before configuring a dynamic trigger timer:
A profile variable of type String exists that will hold the date value. Create it under Profiles → Variables if it does not exist yet.
The date value is being captured into that variable. This typically happens through a variable mapping on an engagement or external fact rule earlier in the journey.
You know the date format of the incoming value (for example,
yyyy-MM-ddordd-MM-yyyy HH:mm).
Note that, currently, dynamic trigger timers can be configured based on a variable defined using a separate journey rather than the current journey where it's configured.
Instructions
Navigate to the journey you want to add the dynamic trigger timer rule, and select the journey condition you want to edit.
Click Add rule and select Dynamic trigger timer from the rule list.
Select the profile variable that contains the date value.
Configure the date format pattern that matches how the date is stored (for example,
yyyy-MM-dd).Configure the time condition that determines when the profile should be released:
Match type: Choose Before or After relative to the date in the variable.
Time frame: Choose In the past or In the future to define which direction the offset applies.
Period: Set the offset amount using minutes, hours, days, or weeks.
Combine with other rules if needed.
Date format reference
The date format must match the format of the value stored in the profile variable. Use the following components to build the format pattern:
Component | Pattern | Example |
|---|---|---|
4-digit year | yyyy | 2026 |
Month number | MM | 03 |
Day of month | dd | 15 |
24-hour time | HH | 14 |
12-hour time | hh | 02 |
Minutes | mm | 30 |
Seconds | ss | 45 |
Fraction of second | S | 0-9 |
Timestamp in milliseconds | x | 1672531200000 |
Common format examples: yyyy-MM-dd, dd-MM-yyyy HH:mm, yyyy-MM-dd HH:mm:ss.
The time zone used for date evaluation is inherited from the site configuration.
Limitations and constraints
Variable type must be String. Only string-type profile variables can be used for dynamic trigger timers. The value must be a parseable date string.
One filter per rule. A dynamic trigger timer can only refer to one variable at a time.
Maximum time horizon is 2 years. If the calculated wait time exceeds 2 years, the engine creates a time gate at the maximum duration. Profiles in this state are not automatically reprocessed, so the trigger effectively becomes dormant unless a new event arrives for the profile.
Date format must match exactly. If the value in the variable does not match the configured date format, the engine cannot parse it and the profile will not advance past the trigger.
Historic processing requires an event-based rule. A trigger that contains only dynamic trigger timer rules (excluding overlap rules) cannot be used for historic processing. Combine it with at least one event-based rule if you need historic processing support.
Variables must have values. If the profile variable has not been set, the engine creates a maximum-duration time gate. The profile advances through the journey only when a subsequent event assigns a value to the variable and the time condition is then met.
Recalculation is event-driven. When a new event arrives that updates the variable value, the time gate is recalculated based on the new value. There is no background process that monitors changes to variables between events.