> ## 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 > Limit how often an automation can fire for a single customer to prevent over-messaging. 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 | Cap | Description | | ---------- | ------------------------------------------------------------------------------------------------------------ | | `EVER` | The automation fires at most once per customer, ever — regardless of how many times the trigger event occurs | | `24 hours` | At most once per customer per 24-hour period | | `7 days` | At most once per customer per 7-day rolling window | | `14 days` | At most once per customer per 14-day rolling window | | `30 days` | At 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. ## Caps and consent filtering 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. Use **`7 days`** or **`14 days`** for recovery and re-engagement flows where repetition makes sense across separate purchase cycles but should not occur in rapid succession. **Best for:** * Abandoned Checkout Recovery — a customer who abandons multiple checkouts in different sessions should be recoverable each time, but not messaged twice in the same week for two abandonments on consecutive days * Post-purchase cross-sell — relevant after each purchase, but not multiple times within the same week A `7 days` cap on an abandoned checkout automation means a customer who abandons twice in the same week is only enrolled on the first abandonment. The second, occurring within 7 days, is skipped. Use **`24 hours`** for flows tied to transactional events that can legitimately recur daily but should not result in multiple messages on the same day. **Best for:** * Order Shipped notifications — a customer who places two orders fulfilled on the same day should not receive two shipping notifications within hours of each other * Back-in-Stock — a customer subscribed to multiple variants restocked on the same day should receive one notification, not one per variant For Order Placed and Order Shipped flows, consider whether a `24 hours` cap might inadvertently suppress legitimate messages for customers who genuinely place multiple orders in a day. Evaluate your order frequency data before choosing this cap. Use **`30 days`** for segment-triggered flows where the underlying segment membership changes regularly and re-enrollment over time is appropriate. **Best for:** * Win-back flows triggered when a customer enters a lapsed-buyer segment — a customer who purchases, lapses, is messaged, and then lapses again after another period deserves re-enrollment after a meaningful gap * Lifecycle nurture flows tied to dynamic segments where customers can exit and re-enter as their data changes A `30 days` cap ensures the same customer does not receive the same win-back flow repeatedly within a single month, even if segment membership fluctuates. ## 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. ## Related guides * [Exclusion Rules](./exclusion-rules) — Excluding entire lists or segments from an automation, independent of caps * [Triggers](./triggers) — Trigger frequency affects which cap is most appropriate * [Activity Tracking](./activity-tracking) — How cap-blocked enrollments are recorded in the activity log