Orchestrating processes in cloud workspaces

Triggers decide when a cloud task starts, and your connectors let it act in the systems you already use. These examples show how to put the two together: a morning sweep on a timer, a webhook that writes its result back, and a pair of tasks that catch each other's gaps.

The building blocks

Each example uses the same four pieces. A trigger starts the run. A connector lets it read and write in another system, with the owner's permissions. A skill holds how to work that system. The task's instructions hold the process: the steps, who approves, who is told.

A morning sweep of your inbox and task tracker

You want each weekday to start with the tasks that were waiting on an email moved forward. Connect your mailbox and task tracker, then ask for a task on a weekday 07:30 schedule with instructions like these. Skill names are examples; use the ones your connectors provide.

# Morning unblock sweep

## Outcome
Tracker tasks that were waiting on an email are moved to Ready, and I get a summary.

## Each run
Cover mail received since 07:30 on the previous working day, London time.

## Steps
1. Load the `mail-search` skill and list messages received in that period.
2. Load the `tracker` skill and list tasks with status Blocked.
3. For each blocked task, check whether a message answers what it is waiting on.
4. If one does, set the task to Ready and comment with a link to the message.
   If it is unclear, change nothing and list it in the summary.
5. Send me the summary.

## Before delivering
Search memory for a receipt for this task and date. Skip anything already done.

## Records
After each change succeeds, record a receipt keyed by task ID and date.

## If something goes wrong
If the mailbox or tracker cannot be reached, change nothing and say so in the summary.

Press Run now and read the conversation before you rely on the schedule. For the first few runs, have the summary go to you and nobody else.

A webhook that writes back through a connector

Your CRM can call a webhook when a deal closes. The task receives the deal's details and does the rest:

  1. The CRM sends the webhook with the deal ID as the Idempotency-Key, so a retry does not start a second run.
  2. The run checks the deal against your billing system through its connector and looks for a customer that already exists.
  3. It creates what is missing: the customer in billing and an onboarding task in your tracker.
  4. It writes back. Using the CRM's connector, it records the new billing ID on the deal, so the people who work in the CRM see the result.

Writes follow the approval rules you already use. A write that needs approval makes the run wait for you under Needs attention. Decide which steps are safe to run unattended, and ask the agent to stop at the rest.

Events with a daily safety net

Webhooks and tickets react instantly but can be missed if a sender fails. Give one task a Webhook or Ticket Events trigger for speed, and give a second task a daily schedule that looks for anything that never got handled, such as deals closed without a billing ID. If both tasks record receipts, the sweep skips work the event runs already finished.

Design tasks that hold up