Re-entry and frequency
Control how often a contact re-enters an automation and how many emails they can receive in a window.
Last updated: May 2026
Re-entry policy
After a contact finishes a run, can the same trigger event re-enroll them? You decide per workflow.
Once
The default. A contact runs through the workflow at most once. Future trigger events are ignored for that contact, forever (per workflow). Use this for welcome series, onboarding, and any sequence that should never repeat.
Multiple with cooldown
Allow re-enrollment after a cooldown period (in hours). Useful for repeated nudges like cart abandonment, re-engagement on the same product, or weekly digests when triggered by a recurring event.
- Cooldown hours: 1 to 8760 (one year). Counted from when the last run completed, not when it started.
- While the cooldown is active, new trigger events for the same contact are silently dropped.
Per-workflow frequency cap
Each workflow has an optional frequency cap that limits how many Send email actions a single contact can receive from that workflow inside a rolling time window. When the cap is hit:
- The Send email action is skipped (logged as capped in the run trail).
- The run advances to the next node.
- Other actions (tag, webhook, notify inbox) still fire.
Defaults: cap off for new workflows. Common settings: 1 email per 24 hours, 3 emails per 7 days. Configure in the workflow Settings panel.
Enrollment locks
Independent of re-entry policy, Grivo holds a per-contact enrollment lock per workflow. While a contact has an active run (any state except completed, failed, cancelled), a second trigger event for the same contact in the same workflow will not start a parallel run.
This prevents duplicate sends from noisy triggers (a chatbot rapid-firing keywords, a list import re-running, etc.). The dropped event is recorded in the workflow log but no new run is created.
Idempotency keys
Every trigger event generates a deterministic sha256 idempotency key (64 chars) based on the workflowId + contactId + eventType + eventSourceId. If the same event arrives twice (network retries, webhook duplicates), Grivo recognizes it and ignores the second one. Calling the manual-trigger API with the same idempotencyKey header is also safe to retry.