Workflow patterns: approvals, retries, loops

Approval chain

Trigger → AI Action (draft) → Human Review → Output. The Human Review step pauses the run and the item appears in the Review Queue (with a bell notification for reviewers). Approving continues down the approved branch; rejecting continues down the rejected branch, where you can notify someone or stop.

Processing each item in a list

Use a For each item step to run a group of steps once per item of a list (for example each row a Read rows step returned), then continue on its "done" output with all the results. Inside the loop, read the current item with {{item.<field>}}. Put a Router inside the loop if items need different handling. Human Review isn't allowed inside a loop: to approve a batch, review the collected {{input.results}} once after "done".

Follow-ups after a delay

Trigger → first action (for example send a welcome email) → Wait ("For a while", e.g. 3 business days, or "Until a date" from the data) → check whether a follow-up is still needed (a Find a row or CRM lookup, then a Router) → follow-up action. The run waits for up to 30 days without using run time and continues on its own.

Remembering across runs

Memory (read) keyed on the contact, e.g. {{trigger.from}} → AI step that includes {{steps.<memory read>.value}} in its prompt → reply → Memory (write) with the same key and a TTL. Put the write after the step that must succeed (for example after the reply is sent), and give the workflow its own namespace.

Retries

Action and Integration steps can retry failed calls (exponential or fixed backoff, or no retries). Add an Error Handler to decide what happens if a step still fails after its retries.

Avoiding duplicates

Use a persistent Memory node to record an ID after you handle an event. At the start of the next run, read that key and use a Router to skip items you've already processed. This matters most for webhooks, which a sender may deliver more than once.

Scheduled daily / weekly digests

Scheduled trigger (for example cron 0 9 * * * for 9am daily, with the run window covering 9am) → HTTP Request (fetch the day's data) → AI Action (summarise) → Send Email or Publish Output to Slack. Use Memory to store a "last sent" timestamp if you need to pick up where the previous run left off.

Grounding AI in your own information

Trigger → Retriever (look up relevant entries from memory or static data) → Agent (with the results in the prompt) → Validator (check the output shape) → Output. Tell the agent to answer only from the information provided.

Undoing earlier steps when a later one fails

For multi-step writes to other systems, add an Error Handler that runs compensating steps (for example cancel the record you created earlier) if a later step fails, and notifies someone.