Skip to main content
This guide creates a weekly renewal-review Workflow. Adapt the pattern to any repeatable process with clear inputs and outputs.

​
1. Prove the process manually

Before automating, run the task once in chat. Attach the Renewal Policy page and Renewals table, then ask:
Find renewals due in the next 90 days. Group them by account owner, flag high-risk records and records without a next action, and produce a CSV plus a concise summary.
Review the result with the process owner. Automation should preserve an agreed process, not hide an unresolved one.

​
2. Describe the Workflow contract

Open Workflows → New workflow, or ask from chat:
Create a workflow named Weekly renewal review. It should accept an optional as-of date, read the Renewals table, select records due within 90 days, group them by account owner, flag high-risk or incomplete records, write a dated CSV to Project files, and return a Markdown summary. It must fail without updating records if the table cannot be read.
Include:
  • trigger and timezone;
  • input types and defaults;
  • data and Knowledge references;
  • output files or records;
  • side effects;
  • retry and failure rules.

​
3. Inspect the definition

Open the Workflow and use the graph view to follow the execution order. Click each node and check:
  • what input it receives;
  • where mapped values come from;
  • what output it produces;
  • whether it can call an external system;
  • what happens when it fails;
  • whether fan-out branches are aggregated correctly.
Use the raw JSON view when you need to verify exact argument names or mappings.

​
4. Ask for changes

Use Ask to edit instead of changing the definition by hand. For example:
Change the workflow so an empty result still creates a summary saying that no renewals are due, but does not create a CSV. Add the table name and as-of date to every failure message.
Reopen the graph and verify the changed branches.

​
5. Run a safe test

Select Run now and provide representative inputs. If the Workflow accepts a file or Project reference, choose it in the generated input form. File inputs can be up to 10 MB each. For the first test:
  • use a copy or a non-critical record set;
  • disable unnecessary external writes;
  • choose a date that produces known results;
  • tell the process owner when the run will happen.

​
6. Inspect the run

Open the run detail and verify:
  • the run status;
  • resolved arguments;
  • each node’s input and output;
  • retries or skipped branches;
  • generated files;
  • external side effects;
  • aggregate results after fan-out.
A failed node should expose an error that identifies the failing operation and relevant input. Fix the definition or dependency, then run a new test.

​
7. Activate a trigger

After a successful manual test, configure the required trigger:
  • manual only;
  • schedule;
  • webhook;
  • supported event.
For a schedule, confirm the timezone and intended day. For a webhook, store the token securely and rotate it if exposed. Update the calling system after rotation.

​
8. Monitor and pause

Review runs regularly, especially after changing:
  • a Source or Knowledge policy;
  • a Data model or table;
  • connector credentials;
  • Workspace or Project membership;
  • the Workflow definition.
Pause the Workflow when its owner, input, or dependency is not trustworthy. Resume it after a successful manual test.

​
Release checklist

  • The process owner approved the expected result.
  • Inputs and outputs are typed and named clearly.
  • Side effects are limited to the intended systems.
  • Failure and retry behavior were tested.
  • A manual run completed with representative data.
  • The trigger and timezone are correct.
  • The owner remains a member of the Project.
  • Someone is responsible for reviewing failed runs.