How to Set Snooze Limits
By default, any agent with the Close/Reopen conversations permission can snooze a conversation for any length of time, from any surface — the snooze dialog, a macro, bulk reply, an automation rule, or the Slack integration. If that’s more flexibility than your workspace wants, you can restrict it in two ways: turn Snooze off entirely, or cap the maximum snooze duration. Whichever you choose, the restriction is enforced consistently across every place a conversation can be snoozed — there’s no surface where an agent can quietly bypass it.
Where to set it
Go to Settings → Conversation handling. There you’ll find the snooze policy controls for your workspace:
- A toggle to disable Snoozed status for the whole workspace.
- A maximum snooze duration, expressed in days and hours, that applies whenever Snooze is enabled.
These two controls are independent. You can leave Snooze on with no cap (the default), leave it on with a cap, or turn it off outright.
Turning off Snooze entirely
Flip the toggle off, and the Snoozed status stops being available across the workspace. Agents can’t snooze a conversation from any surface:
- The Snooze action disappears from the conversation action bar, and the
Zkeyboard shortcut no longer opens the snooze dialog. (The command palette never carried a snooze action; its Go to snoozed conversations entry is navigation and stays put.) - A macro that sets status to Snoozed skips that part of the macro rather than failing silently — the agent sees a toast explaining that snooze is off and the status wasn’t changed.
- Bulk reply removes Snoozed from the status dropdown, so it’s not an option to begin with.
- Automation rules and the Slack integration can no longer move a conversation into Snoozed either.
Existing conversations that were already snoozed before you turned the toggle off aren’t affected — they still wake up on schedule. The toggle only stops new snoozes from being created.
Capping the maximum snooze duration
If you’d rather keep Snooze available but limit how far out agents can push a conversation, leave the toggle on and set a maximum snooze duration (days/hours). This puts a ceiling on the wake time an agent — or a macro, an automation, or Slack — is allowed to choose.
Once a cap is set:
- The quick-option presets are filtered. In the snooze dialog and the macro editor, a preset longer than the cap isn’t offered. The dialog’s Snooze until box is free text, though, so an agent can still type “6 months”: the server refuses it and answers with the limit. And a macro that already stored an over-cap preset keeps showing it, so an admin editing that macro can see what it holds.
- A cap also makes a wake time mandatory. With a cap set there is no way to snooze “indefinitely”: a request with no wake time is refused, because no wake time outlasts any cap. (Without a cap, nothing forces one — see the note under the table.) This applies uniformly to the snooze dialog, macros, automation rules, and the Slack integration’s snooze action.
- Bulk reply behaves more strictly than the other surfaces. Bulk reply doesn’t have a way to prompt for a wake time, so as soon as any cap is set — even a generous one — Snoozed is removed from the bulk reply status dropdown entirely. Bulk reply only offers Snoozed when Snooze is on and there’s no cap at all.
How the limit surfaces to agents
- Action bar / keyboard shortcut (
Z) — Snooze action is hidden; shortcut does nothing — Unaffected — agent can still open the snooze dialog - Snooze dialog — Not reachable — Quick-option presets beyond the cap are filtered out; a typed time beyond it is refused by the server
- Macros — Snooze step is skipped with a toast (“Snooze is off for this workspace. The status was not changed.”) — New presets are offered in-cap only, but a macro that already stored an over-cap preset still shows it; if that preset is used at run time, the agent sees a refusal toast with the server’s reason
- Bulk reply — Snoozed removed from the status dropdown — Snoozed removed from the status dropdown whenever a cap exists (bulk reply can’t collect a wake time)
- Automations — The
Set statusaction still offers Snoozed in the builder; the rule is refused when it runs, and the reason is logged — The rule is refused at run time if it would snooze without a wake time inside the cap - Slack integration — Snooze action refused — Snooze action refused unless the requested wake time is within the cap
The common thread: once a cap exists, wherever a wake time can’t be supplied — or would fall outside your cap — the snooze attempt is refused rather than silently applied with no wake time.
That guarantee comes from the cap, not from Snooze itself. In a workspace with Snooze on and no cap, a wake time is optional: an automation’s Set status → Snoozed action carries none, and with no cap to breach the policy allows it, so the conversation is parked with nothing scheduled to wake it. If you want every snoozed conversation to come back on its own, set a cap — even a generous one.
Choosing between “off” and “capped”
- Turn Snooze off if your team shouldn’t be deferring conversations at all — for example, a workspace that wants everything either Active or Done/Archived.
- Set a cap if you want to keep the flexibility of snoozing but stop agents from pushing conversations weeks or months into the future, where they’re effectively forgotten.
Either setting takes effect immediately for new snooze actions; it does not retroactively change conversations that are already snoozed.