Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.digifist.com/llms.txt

Use this file to discover all available pages before exploring further.

Frequency caps control how often a specific automation can enroll and message a single customer. They are a guardrail against over-messaging — without them, a high-frequency trigger like ORDER_PLACED or USER_ADDED_TO_SEGMENT could enroll the same customer multiple times in rapid succession, sending them several messages from the same flow within hours or days. Every automation should have a frequency cap configured. It is one of the factors Galantis validates before a flow can be activated.

​
What this covers

  • The five available frequency cap options
  • How caps are enforced
  • How caps interact with consent filtering
  • Choosing the right cap for each automation type

​
Available frequency caps

CapDescription
EVERThe automation fires at most once per customer, ever — regardless of how many times the trigger event occurs
24 hoursAt most once per customer per 24-hour period
7 daysAt most once per customer per 7-day rolling window
14 daysAt most once per customer per 14-day rolling window
30 daysAt most once per customer per 30-day rolling window
When a customer is blocked by a frequency cap, the trigger event is detected but the customer is not enrolled into the flow for that occurrence. The block is recorded in the automation’s activity log.

​
How caps are enforced

Frequency caps are evaluated at the trigger level — at the moment a trigger event fires for a customer, Galantis checks whether the customer has been enrolled in this automation within the cap window before proceeding. If the customer is within the cap window, they are not enrolled for that trigger occurrence. The next trigger event for that customer after the cap window expires will enroll them normally. Frequency caps and consent validation are independent checks that both apply before enrollment:
  1. Consent check — Is the customer’s marketing_state = SUBSCRIBED? If not, skip.
  2. Frequency cap check — Has this customer been enrolled within the cap window? If yes, skip.
A customer must pass both checks to be enrolled. Passing the consent check does not bypass the cap, and the cap window does not affect consent status.

​
Choosing the right cap

Use EVER for automations that represent a single lifecycle event — something that should happen once and only once per customer regardless of how many times the underlying trigger fires.Best for:
  • New Customer Welcome — a customer should receive a welcome message once, even if they place multiple orders
  • VIP tier promotion — a promotion sent when a customer first reaches VIP status should not repeat each time they place an order while VIP-tagged
  • Any flow tied to a first-occurrence milestone
EVER caps are permanent. Once a customer has been enrolled and the cap is applied, they will never be enrolled in that automation again, even if the automation’s content changes significantly. For flows you may want to re-run after a long period, use a 30 days cap instead.

​
Best practices

  • Set a cap on every automation before activating. An automation without a frequency cap is a configuration gap — even for triggers that seem unlikely to fire repeatedly, a cap provides a safety net.
  • Review cap settings when changing trigger logic. If you change a trigger from ORDER_PLACED to USER_ADDED_TO_SEGMENT, the appropriate cap may also change. Revisit cap configuration whenever the trigger is updated.
  • Use EVER cautiously on long-lived automations. A welcome flow with an EVER cap is correct. A promotional cross-sell with an EVER cap means customers are permanently excluded from that automation after one enrollment — which may not be the intent if the automation runs for years.
  • Exclusion Rules — Excluding entire lists or segments from an automation, independent of caps
  • Triggers — Trigger frequency affects which cap is most appropriate
  • Activity Tracking — How cap-blocked enrollments are recorded in the activity log