Capping Rules Are Not Frequency Rules: A Field Guide
They're configured in different places, evaluated at different layers, and suppressing messages for different reasons. Confusing them is the most common delivery failure in AJO. Here's the exact distinction and how to debug it.
Two Systems, One Outcome, Zero Visibility
Profiles are being suppressed. Messages aren't sending. You check the journey — re-entry looks fine. You check the channel — the surface is active. But the send volume is still lower than it should be.
The likely culprit is a capping rule conflict — and the reason it's hard to diagnose is that AJO has two entirely separate systems that both suppress message delivery, configured in different places, evaluated at different layers, with different logging.
Confusing them is the most common configuration error I see in production AJO environments.
The Distinction That Matters
| Journey Re-Entry Rules | Rule Set Frequency Caps | |
|---|---|---|
| Where configured | Journey Properties → Re-entry settings | Administration → Rule sets |
| Scope | Single journey | Across multiple journeys and campaigns |
| What it controls | Whether a profile can re-enter this journey | How many messages a profile can receive across all journeys |
| Evaluation timing | At journey entry | At message execution |
| Logging location | Journey step events | Rule set suppression logs |
Common Mistake: Increasing the re-entry window on a journey to fix suppression, when the actual block is a rule set cap applied at the channel level. The re-entry change does nothing — the profile enters the journey but gets suppressed before the message executes.
How Rule Sets Actually Work
Rule sets are applied at the channel surface level, not at the journey level. This means:
- A profile enters a journey — no block at entry
- The journey executes — wait steps, conditions, all pass
- The message action fires
- AJO checks rule sets before delivery
- The profile has already received 5 emails this week
- The rule set cap is 5 emails per week
- Message is suppressed — no delivery, no error, just silence
The journey reports the message as "attempted." The rule set logs the suppression. If you're only looking at journey analytics, you'll never see it.
The Three Layers of Suppression
A single profile can be blocked at any of these layers simultaneously:
Layer 1 — Journey re-entry rules Set in Journey Properties. Controls whether a profile that has already been in this journey can enter again, and after what time window.
Layer 2 — Rule set frequency caps Set in Administration → Rule sets → Business rules. Applied across journeys and campaigns. Can be configured by channel (email, push, SMS) and time window (daily, weekly, monthly, all time).
Layer 3 — Channel surface limits Set in Administration → Channels → Channel surfaces. Hard limits on message volume per profile per time period at the infrastructure level.
Each layer has its own logging. There is no single dashboard that shows you all three simultaneously.
How to Diagnose a Suppression Issue
Step 1 — Check journey step events
In AEP → Query Service, run a query against journey_step_events for the affected profile. Look for step status = "suppressed" or "discarded."
Step 2 — Check rule set logs Go to Administration → Rule sets → select the relevant rule set → view suppression log. Filter by profile ID and date range.
Step 3 — Check the channel surface configuration Go to Administration → Channels → find the surface used by the affected journey action. Review the frequency settings.
Step 4 — Check the profile's message history In AEP → Profile viewer → select the profile → Message Feedback Events. This shows every message sent or attempted across all journeys and campaigns.
The Configuration Audit Checklist
Run this before every major campaign launch:
- List every rule set currently active — confirm which channels and journeys they apply to
- Check the re-entry setting on this journey — is it set intentionally or left at default?
- Check the channel surface frequency limits — do they align with your intended send cadence?
- Pull a sample of profiles who should have received the message — trace suppression for each
- Confirm suppression logging is enabled so you can audit post-send
Best Practice: Document your rule set architecture the same way you document your journey logic. Every team that inherits an AJO environment without this documentation spends the first two weeks discovering suppression rules that nobody remembers creating.
If your send volumes are lower than expected and journey analytics look clean, the problem is almost certainly in the capping layer. Book a diagnostic session → and I'll map your full suppression architecture in a single call.