Envelope

Scheduling and triggers

Teams can run automatically in three modes — on a time-based schedule, when an external event fires, or when a plain-English condition is met. All three are available on all plans including Free.

Trigger types

| Type | How it fires | Best for | |---|---|---| | Scheduled (cron) | At a fixed time — hourly, daily, weekly, or custom | Regular recurring work: reports, digests, data syncs | | Event | When an inbound webhook arrives from an external system | React to external signals: new ticket, merged PR, deal update | | Condition | Polls at an interval; runs only if a lightweight AI check says yes | Monitor-and-act patterns: stale deal, threshold crossed, anomaly detected |

Scheduled (cron)

Set a team to run at a fixed cadence. The schedule fires regardless of what is happening in the world — the team always runs when the time comes.

Setting up a schedule

In the room thread, tell the assistant you'd like to set a schedule — for example, "Run this every weekday at 9am." A Schedule card appears inline in the thread.

Click any preset to apply it immediately, or click Custom time to choose your own frequency, time of day, and timezone. When you're done with a custom schedule, click Save schedule.

Cadence presets

| Preset | What it does | |---|---| | Every weekday 9am | Fires Monday to Friday at 9am in your selected timezone | | Every Monday 9am | Fires once a week on Monday at 9am | | Daily at noon | Fires every day at 12pm in your selected timezone | | Every hour | Fires at the top of every hour | | Custom time | Set your own frequency (Daily, Weekdays, Weekly (Monday), or Every hour), time of day, and timezone |

Timezone

Select a timezone so the schedule fires at the right local time. Envelope adjusts for DST automatically for regions that observe it.

Supported timezones: UTC, EST — UTC−5, CST — UTC−6, MST — UTC−7, PST — UTC−8, BST — UTC+1, CET — UTC+1, IST — UTC+5:30, SGT — UTC+8, JST — UTC+9, AEST — UTC+10, NZST — UTC+12.

If your use case is time-insensitive, use UTC to avoid any DST ambiguity.

Event trigger

The team fires when an external system sends a webhook to Envelope. Any tool that can make an HTTP POST can be the trigger — GitHub, Zendesk, HubSpot, Zapier, Make, or your own code.

How it works

  1. Set the trigger type to Event in the Schedule section of the team editor, or say "trigger this when…" in the room thread and describe the source.
  2. Envelope generates a unique webhook URL and an HMAC-SHA256 signing secret.
  3. Copy both into the source system — configure it to POST to the webhook URL and sign requests with the secret.
  4. Each time the webhook is called with a valid signature, Envelope fires a run.

Security

Every inbound webhook is verified using HMAC-SHA256. Requests with a missing or invalid X-Envelope-Signature header are rejected with 401. Regenerating the secret invalidates all existing signatures immediately — update the source system before regenerating.

Condition check

The team polls at a chosen interval. Before firing the full team, Envelope runs a lightweight AI pre-check using a plain-English prompt you write. The full team only runs if the pre-check returns a positive signal.

This keeps inference costs manageable. The pre-check uses a fast model; the full team only runs when it matters.

How it works

  1. Set the trigger type to Condition in the Schedule section, or describe it in the room thread: "Run this only when there are unresolved support tickets older than 48 hours."
  2. Write a condition prompt — a plain-English description of what to check.
  3. Choose a polling interval: 15 min, 1h (default), 6h, or 24h.
  4. At each interval, Envelope evaluates the condition. If positive, the full team runs. If not, it waits for the next tick.

Writing a good condition prompt

The prompt should describe a specific, checkable state — not a goal or instruction.

Good: "Are there any open Zendesk tickets with priority 'urgent' that have not been updated in the last 4 hours?"

Too vague: "Check if there are any issues."

Too imperative: "Look at the tickets and triage them." (This is a run instruction, not a condition check.)

Document-backed condition triggers

If your team uses a workspace document, you can declare condition triggers directly in the document's workspace block rather than writing a freeform condition prompt. The trigger fires when any unblocked row has a status column matching the declared value — evaluated against a lightweight status index with no model call.

This is more reliable than a freeform prompt for status-driven workflows, and it fires at the same polling intervals as a standard condition trigger. Rows with a non-empty blocked-by field are excluded. See Workspace documents → and Creating a team →.

Polling intervals

| Interval | Use when | |---|---| | 15 min | Near-realtime monitoring — SLA violations, critical alerts | | 1h | Standard monitoring — regular deal checks, pipeline health | | 6h | Low-frequency checks — daily batch conditions | | 24h | Once-a-day signals — morning check before a scheduled action |

If you need sub-15-minute response, use an event trigger instead.

Autonomy and human gates

All three trigger types work with human gates identically. Whether a run fires from a clock, a webhook, or a condition check, the gate configuration determines what happens next.

Proactive teams (event or condition) with no gates run fully autonomously — observe and act without any human checkpoint. This is a legitimate and useful configuration but you should opt in knowingly. The team editor shows a reminder when saving a proactive team with no human gates configured.

To observe autonomously but pause before acting, add a human gate before any action step. See the human gates guide →

Run provenance

Every run stores how it was triggered. In the room thread, runs fired by event or condition triggers show a small EVENT or CONDITION badge next to the run status so you can see at a glance why a run appeared without you initiating it.

‹ All guidesDocs ›