Is there a way in automations to wait for a certain property to change before it branches? Currently, branching evaluates the property’s current value immediately at that step in the workflow.
We have an onboarding automation where users receive a “Your free trial ended” email after a 14-day wait step. However, users sometimes request and receive trial extensions. When that happens, the automation still sends the “trial ended” email at day 14 even though their extended trial hasn’t actually expired yet.
What is the recommended approach to handle property changes or delay the branch until real expiry?
Hey,
We don’t currently have a native wait-until-property-changes / wait-with-timeout step in automations.
Here are the two recommended ways to handle trial extensions cleanly:
1. Trigger a separate event-based automation when the trial actually ends (Recommended)
Instead of relying on a static 14-day wait timer in a single automation, you can trigger a separate workflow when the user’s trial genuinely expires:
When a user’s trial ends on your backend (whether after 14 days or after an extension), send a custom event or update a contact property via the API:
// POST https://api.autosend.com/v1/events/send
{
"eventName": "trial.expired",
"email": "user@example.com",
"eventProperties": {
"trialDurationDays": 21,
"extended": true
}
}
Or update a contact property such as trialEnded: true.
That event or property update can then trigger your “Free Trial Ended” automation. This naturally handles users whose trials were extended, since the event will only fire when their trial actually concludes on your backend.
2. Check the trial status before sending the email
If trial extensions are always for a fixed duration (e.g. 7 days), you could keep the existing workflow and add a Branch condition after the 14-day wait step:
- If trial has ended (
trialExtended == false) → send the “Your free trial ended” email.
- If trial was extended (
trialExtended == true) → route to an additional wait step (e.g. wait 7 days) and then send the email.
Note: The first approach (event-driven trigger) is significantly more reliable and scalable if trial durations or extension periods vary across users.
Relevant Documentation