Home Administrator's First Steps Snooze automations with a deadline

Snooze automations with a deadline

Last updated on Jul 20, 2026

When to use

  • You want an automation to put the conversation into Snoozed state and reopen it on its own after some time.
  • You want to choose how long the conversation stays snoozed (1 hour, until tomorrow, 1 month, custom time).
  • You are building a follow-up flow and need the ticket to come back at the right moment.
  • You ran into the most common problem: the Snooze automation keeps re-snoozing the conversation every time the customer replies ("loop").

What the action does

The Snooze Conversation automation action puts the conversation into the Snoozed state. You can now choose when it should reopen:

Option What it does
Until the next user message Snoozes with no deadline: reopens when the customer replies
In 1 hour Reopens 1h after the rule runs
Until tomorrow Reopens tomorrow morning (9 AM)
Until next week Reopens next Monday (9 AM)
For 1 month Reopens at the start of next month (9 AM)
Custom time You set the duration (number + hours/days/weeks)

The deadline is always relative to the moment the rule fires (e.g., "in 1 hour" = 1h from now), never a fixed date.

How each deadline is calculated

Always counting from the moment the rule fires:

Option Reopens at…
Until the next user message No fixed time — only reopens when the customer replies
In 1 hour Exactly 1 hour after firing (fired at 2:37 PM → reopens at 3:37 PM)
Until tomorrow The next day, at 9 AM
Until next week Next Monday, at 9 AM
For 1 month The first Monday of the following month, at 9 AM
Custom time Now + the chosen duration (number × hours/days/weeks), capped at 1 year

Details that avoid surprises:

  • The "until tomorrow / next week / 1 month" options always land at 9 AM (start of business hours), not at the exact time the rule ran.
  • "For 1 month" is not "30 calendar days" nor "the same day next month": it is the first Monday of the next month, so the ticket comes back at the beginning of a business week.
  • "In 1 hour" keeps the minutes of the firing time (it does not round up to the top of the hour).
  • These rules are identical to manual snooze — the automation simply reuses the same logic.

How a snoozed conversation reopens

There are two paths for a snoozed conversation to reopen:

  1. The customer replies — any snoozed conversation reopens automatically when it receives a new customer message (default Cloud Chat behavior, regardless of the deadline).
  2. The deadline is reached — if you snoozed with a deadline, it reopens on its own when the deadline arrives.

Watch out: the re-snooze "loop"

This is the behavior that causes the most confusion.

If you create a Snooze automation on the Conversation Updated event with a condition that stays true (e.g., a tag that remains on the conversation), it will re-snooze the conversation every time the customer replies.

Why: when the customer replies, the conversation reopens. That reopening counts as an "update" to the conversation → the rule fires again → and, since the condition (the tag) is still there, it snoozes it once more. It becomes a cycle.

This is not a bug — it is the natural behavior of event-driven automations. The fix is to design the rule so it does not repeat.

Best practices: how to avoid the loop

The core idea: make the rule "consume" whatever triggered it, so the trigger only counts once.

Option A — Remove the tag that triggered the rule (simplest)

In the same rule, add two actions:

  • Snooze Conversation → (the desired period)
  • Remove label → the trigger tag

That way, when the conversation reopens on the customer's reply, the condition (tag = X) is already false → the rule does not re-snooze.

Option B — Use a custom attribute as a "step/flag"

Instead of a tag, use a custom attribute (e.g., followup_step) and advance/clear it at each step. Useful when you want to control how many times the automation runs.

Choose the right event

  • Conversation Created → fires only when the ticket is born (does not re-fire on replies). Ideal for "snooze every new ticket from a given inbox". Note: tag-based conditions usually do not work here, because tags are typically applied after creation.
  • Conversation Updated → required for triggers based on tag/attribute (applied after creation). Here, always use the consume the tag pattern (Option A/B) to avoid repeating.

Practical example: a follow-up flow

Goal: "conversation tagged follow-up → wait X, send a message, wait again, and close if the customer does not reply".

  • Rule 1 — Start
    • Event: Conversation Updated · Condition: has the tag follow-up
    • Actions: Snooze (e.g., for 1 day) + Remove label follow-up + Add label followup-1
  • Rule 2 — Follow-up
    • Event: Conversation Updated · Condition: has the tag followup-1
    • Actions: Send message (follow-up) + Snooze (e.g., for 1 day) + Remove followup-1 + Add followup-2
  • Rule 3 — Close
    • Event: Conversation Updated · Condition: has the tag followup-2
    • Actions: Send final message + Resolve + Remove followup-2

Each rule removes its own tag and passes the next one along — that is why there is no loop, and the sequence moves forward in a controlled way. If the customer replies in the middle, the conversation reopens and a human agent takes over normally.

Notes

Do's & don'ts:

  • ✅ Every Snooze-by-tag rule must remove the tag that triggered it (or use an attribute as a step).
  • ✅ To snooze new tickets, prefer the Conversation Created event.
  • ✅ Use the deadline when you want it to reopen on its own after some time; use "until the next message" when you want it to reopen only on the customer's reply.
  • ❌ Do not leave a Snooze rule on Conversation Updated with a condition that never stops being true — it will re-snooze on every reply.