HubSpot offers two trigger paradigms: property-based (fire when criteria become true) and scheduled (fire on a clock). They look interchangeable for some use cases. They are not. Pick the wrong one and you get duplicate sends, missed contacts, or both.
Property-based: event reaction
Use property-based triggers when the workflow exists to react to a state change. Lifecycle stage moves to MQL, deal stage moves to Closed Won, contact downloads an asset. These are events; the workflow is the response. Latency is low; HubSpot enrolls within minutes.
Scheduled: time-based campaigns
Use scheduled triggers when the workflow exists to act on a population at a moment in time. Monthly newsletter, quarterly NPS, weekly digest, birthday email. The audience is dynamic via a list, but the timing is the calendar.
The trap: scheduled with property re-enrollment
A scheduled workflow that also re-enrolls on property change can fire twice for the same contact. Once on the schedule, once on the property change. Pick one mode per workflow. If you need both, use two workflows with explicit suppression between them.
The trap: property-based with date filters
A property-based workflow with a filter like “renewal date is in next 30 days” appears to be time-aware, but the filter is evaluated only at enrollment. A contact whose renewal date later falls into the window will not be enrolled unless you also re-enroll on date change. Use scheduled for date-window logic.
Race conditions on parallel mutations
If one workflow updates lifecyclestage and another updates lead_status and both are property-based, the order is not guaranteed. Build idempotent actions and avoid one workflow’s outcome being a precondition for another. Where order matters, chain explicitly with goal lists.
Time zone subtleties
Scheduled triggers run on the portal’s time zone (Settings > Defaults). A 9 AM scheduled send for a global audience is 9 AM portal local, not per-recipient. For per-recipient timing, use Send Time Optimization on the email step or split the workflow by region with separate schedules.
When to use both deliberately
A nurture sequence triggered by lifecyclestage = MQL (property) with delays inside that approximate scheduled cadence (every 3 days, 7 days, 14 days) is fine. The trigger is the event; the cadence inside is sequential. This is the correct use of mixing.
Decision flowchart
Ask: what changed to make this workflow needed? If the answer is “a fact about the contact,” use property-based. If the answer is “the calendar reached a date,” use scheduled. If both, build two workflows.
What to do this week
Audit any workflow that uses both scheduled triggers and re-enrollment on property change, pick the single intended trigger mode, and document the choice in the workflow description.
