Skip to main content
A Workflow executes repeatable work consistently. It connects a trigger to a directed sequence of steps, records each run, and makes failures inspectable. The recommended pattern is to explore a process in chat first, then compile it into a Workflow when the steps and expected outcome are clear.

​
When to create a Workflow

A Workflow is a good fit when:
  • the process happens repeatedly;
  • inputs and outputs can be described clearly;
  • the same decisions or transformations recur;
  • the team needs execution history;
  • timing or an external event should start the process.
Use a Process Skill instead when the main goal is to preserve reusable instructions that the assistant can follow interactively. See Process Skills.

​
Create and edit

You can start a Workflow from the Workflows page or ask for it in chat. A strong request states:
  • the trigger;
  • required inputs;
  • ordered steps and decision rules;
  • systems, Sources, Knowledge, or Data it may use;
  • expected outputs;
  • failure and escalation behavior.
Example:
Create a scheduled workflow that runs every Monday, finds renewals due in the next 90 days, groups them by account owner, flags records without a next action, and writes a dated CSV summary to Project files.
Cromo stores the Workflow as a definition that you can inspect as a graph or raw JSON. To change it, use Ask to edit and describe the required change in chat.

​
Triggers

A Workflow can start:
  • Manually — a person selects Run now and provides any required arguments.
  • On a schedule — Cromo starts it at the configured time.
  • From a webhook — an external system calls a Workflow URL.
  • From an event — a supported Project event starts the run.
Webhook credentials can be rotated. Update the calling system after rotation because the old token should no longer be used.

​
Inputs

Manual runs display a form based on the Workflow’s argument schema. Inputs can include text, numbers, dates, structured values, files, and Project references when the definition supports them. Workflow file inputs are limited to 10 MB per file.

​
Runs and steps

Each execution is a run. A run can be queued, running, succeeded, failed, cancelled, or stopped by a billing limit. Open a run to inspect:
  • arguments and resolved inputs;
  • each step’s status;
  • input and output mappings;
  • retries and errors;
  • fan-out branches and aggregate results;
  • produced files or records.
Individual steps can be pending, running, succeeded, failed, skipped, or retrying. Run history remains useful for audit and troubleshooting even when the Workflow definition later changes or is removed from the active list.

​
Activate, pause, and control

After testing, activate the trigger that should run automatically. Pause a Workflow when its context, connected system, or owner is no longer reliable. Resume it only after resolving the condition. Cromo can enforce limits on language-model cost. A Workflow may pause or stop when the configured billing limit is reached.

​
Workflow prompts to try

​
Schedule a recurring review

​
React to an incoming event

​
Run a process on demand

​
A safe release checklist

  • Run the Workflow manually with representative, non-critical input.
  • Compare every side effect with the expected result.
  • Confirm the owner still belongs to the Project.
  • Verify connector permissions and credentials.
  • Check retry behavior for steps that write to external systems.
  • Confirm schedules and webhook callers target the intended Workflow.
  • Make failures visible to the person responsible for the process.
Never activate a business-critical Workflow based only on a plausible-looking definition. Test the complete path, including errors and external side effects.

Build and run a Workflow

Follow the complete drafting, testing, activation, and monitoring process.