> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gocromo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows

> Turn a proven process into a repeatable automation with triggers, typed inputs, run history, and control.

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](/concepts/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

```text theme={null}
Create a workflow that runs every Monday morning, finds open invoices with an
exception, groups them by owner, writes a dated review file, and returns a
summary. It must never change approval or payment status.
```

### React to an incoming event

```text theme={null}
Create a workflow that starts when a complaint email arrives, classifies it
against our Escalation Policy, creates a Ticket record, calculates the response
deadline, and flags critical cases for human review. Keep the acknowledgement
as a draft.
```

### Run a process on demand

```text theme={null}
Create a manual workflow that accepts a purchase request reference, checks it
against the purchasing policy, and returns missing information, required
approver, policy citations, and next action. It must not approve the request.
```

## 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.

<Warning>
  Never activate a business-critical Workflow based only on a plausible-looking definition. Test the complete path, including errors and external side effects.
</Warning>

<Card title="Build and run a Workflow" icon="diagram-project" href="/guides/build-and-run-a-workflow">
  Follow the complete drafting, testing, activation, and monitoring process.
</Card>