Frequency Capping (Touching Rules)

Touching Rules are Joryio's frequency capping: workspace-level limits on how many times you may "touch" each individual user - per channel, per time window. Once a user is at a cap, further sends to them are skipped until the window rolls over, no matter which campaign or journey tries to reach them.

Open Settings → Touching Rules in the dashboard to configure them. (Viewing requires the touching_rules:read permission.)

Anatomy of a rule

Each channel card holds an on/off toggle and 1 to 4 rules. Every rule says:

Max N messages per Day / Week / Month, applying to all messages or only to messages carrying certain tags.

Rules on a channel are AND-ed: a send must be under every applicable rule's cap, and the first rule that is at or over its cap blocks the send.

Tag scoping

• A rule with no tags applies to every message on that channel.
• A rule with tags only counts and caps messages that carry at least one of those tags (OR within the rule). Tags come from the same workspace-wide pool you use on campaigns, journeys, and templates - see Tags.

This makes layered policies possible, as the settings page itself points out: "3 push/day for #promo AND 10 push/day overall" is two meaningful caps, not a redundant pair. If two rules on the same card share both the window and the tag scope, the page flags them as Redundant - the stricter one wins, so add a tag to differentiate or remove one.

Channels

Channel	In-product guidance
Push Notifications	Recommended: 5–10 / day for optimal engagement.
Email Messages	Recommended: 3–7 / week to avoid spam complaints.
SMS Messages	Recommended: 1–3 / week - SMS is the most expensive channel.
In-App Messages	Recommended: 10–20 / day - least intrusive channel.
WhatsApp Messages	Recommended: 3–5 / day to comply with WhatsApp policies.
Viber Messages	Recommended: 3–5 / day to comply with Viber policies.
Webhook Calls	Recommended: 30–50 / day, depending on integration.

All channels ship disabled by default - no capping happens until you switch a channel (or the cross-channel limit) on and save.

The cross-channel limit (master rule)

Above the per-channel cards sits the Cross-channel limit. When enabled, it is a ceiling on the user's total touches across every channel that actually reaches the person - a user could be under every per-channel cap and still be blocked because the combined ceiling is reached. It supports the same 1–4 tag-scoped rules as any channel. In-app impressions count toward this ceiling too.

Webhook calls do not count toward the cross-channel ceiling. A webhook fires an HTTP request at another system; nothing arrives with the contact, so a nightly CRM sync must not spend someone's combined allowance and block a real email. This is only about the combined ceiling - the per-channel webhook cap is unchanged and still counts every webhook call, because rate-limiting calls to a partner API per contact is exactly what it is for.

The page's overview bar visualizes this: each enabled channel's untagged budget stacks into a bar, with a dashed line marking the cross-channel ceiling. If the per-channel budgets add up to more than the ceiling, the overage is shown as "capped" - the ceiling wins. (Tagged rules cap subsets and are not included in that overview.)

What counts as a "touch"

Caps are counted against the user's real, recorded message history - not per campaign:

• Email, SMS, push, WhatsApp, Viber - each successfully dispatched message (the message.sent event). These count toward both their own channel cap and the cross-channel ceiling.
• Webhook - each dispatched call counts toward the webhook cap only, never toward the cross-channel ceiling (see above).
• In-app - in-app messages are pulled by your app rather than pushed, so the impression (the in_app.displayed event) is what counts.
• Count failed deliveries (under Additional settings, off by default) - when on, failed delivery attempts (message.failed) also consume budget on the push-style channels. In-app has no failure event, so this doesn't apply there.

Because counting reads the shared event stream, touches from campaigns and journeys accumulate together against the same caps.

Time windows

"Per day / week / month" is measured against your workspace's timezone (set in workspace settings), not the server clock:

• Day - since midnight, workspace time.
• Week - since Monday 00:00, workspace time (ISO week).
• Month - since the 1st of the month, workspace time.

Windows are calendar-anchored, not rolling: at the boundary everyone's count starts from zero again.

What happens to a blocked send

A send that hits a cap is skipped, not delayed. (Contrast with quiet hours, which defer a message to the end of the quiet window.)

• Campaigns - the over-cap user is skipped during the send and a message.skipped platform event is recorded with reason frequency_cap, so you can see exactly who was capped and why. See Platform events.
• Journeys - the message node is skipped for that user and the journey continues down its path; the skip is recorded the same way. A skipped message never blocks the rest of the journey.
• Webhook nodes - gated by default like any message (a webhook often triggers a user-facing touch in another system), so a call can still be held back by the webhook cap or by a cross-channel rule even though it never spends combined budget itself. A node's System call - skip quiet hours & frequency caps option opts a pure system-to-system call out of both gates; see Canvas nodes.
• In-app - a user at their in-app cap simply isn't shown eligible in-app messages until the window rolls over.

Order of evaluation

Frequency caps are one gate in the send pipeline. A message must first pass suppression lists, consent/subscription checks, and quiet-time; then the frequency caps run; send-volume rate limits apply after that. So a cap only ever "spends" budget on messages that were otherwise going to be delivered.

Within the caps themselves:

1. Only rules whose tag scope matches the message's tags participate.
2. Every applicable per-channel rule is checked, then every applicable cross-channel rule.
3. The first rule at or over its cap blocks the send; otherwise it proceeds.

Related controls that are not frequency capping:

• Suppression Lists - exclude segments entirely, cross-channel.
• Send volume and rate limits - throughput shaping (messages per minute, total volume), not per-user caps.

Bypassing caps for a specific message

Individual campaigns and journey message nodes have an Ignore Touching Rules (Frequency Limits) option that bypasses workspace-level capping for that send only. The settings page's own guidance: use it for security alerts, transactional receipts, legal notices, and account status changes - not for promotions. In campaigns it lives in the delivery step alongside the quiet-time override; in the journey builder it's in each message node's advanced delivery options.

Two things to know about the override:

• It skips the check and the count for that message - but the message still lands in the event stream as a real send, so it does consume other messages' budget going forward.
• Suppression lists still apply; the override never resurrects a suppressed or unsubscribed user.

Editing and saving

Changes take effect when you press Save Settings - new rules apply to sends within about a minute (settings are briefly cached on the sending fleet). Reset reloads the last saved state, discarding unsaved edits.

Reliability notes

• Caps are enforced atomically: two journey executions racing to send the last allowed message to the same user cannot both slip through.
• The system is deliberately fail-open: if the counting infrastructure is briefly unavailable, messages are delivered rather than blocked. A frequency cap will never hard-stop your sending on an infrastructure blip.