Building
Workflows & triggers
Fixed sequences that run when something happens — including the steps that stop and wait for a person.
A worker uses judgment. A workflow follows a sequence. When the steps are the same every time — and especially when a human has to sign off partway through — you want a workflow.
Find them under Workflows.
Anatomy
A workflow is a trigger plus ordered steps.
Triggers
| Trigger | Fires when |
|---|---|
| Record created | A new record of a given type appears |
| Record updated | An existing record changes |
| Schedule | A time you set — cron-style or in plain language |
| Manual | You start it, on a specific record |
Steps are either:
- Automatic — the workflow performs an action: write a record, send an email, call a connected tool, generate a document.
- AI — a step that thinks: classify this, summarise that, decide which branch applies. Use these where the rule is fuzzy but the sequence isn’t.
- Manual — the workflow stops and waits for a named person to complete the step. It stays waiting for as long as it takes.
An example
When an invoice is created: check it has a PO number; if it’s over $10,000, ask Dana to approve it; once approved, file it and notify the client.
That’s four steps, one of which is a human gate. The instance sits at “waiting for Dana” until Dana acts, then continues on its own.
Instances
Every time a workflow fires, it creates an instance bound to the record that triggered
it. An instance is running, waiting, completed, failed or cancelled.
Open a workflow to see its instances: which step each one is on, how long it’s been there, and what it produced. Cancel an instance that’s stuck or no longer relevant.
If nothing happens when you expected it to, the instance list is the first place to look — either there’s no instance (the trigger didn’t match) or there’s one sitting on a step (something is waiting).
Triggers on their own
You can also set triggers independently of a workflow: a rule that watches your records
and does one thing when a condition is met. Simpler than a workflow, right for a single
reaction — “when a lead reaches won, add it to the customers view.”
Each trigger keeps an execution history, so you can see it firing (or see that it isn’t).
Scheduled jobs
Everything time-based across the workspace — scheduled workers, scheduled workflows, recurring triggers — appears together under Scheduled jobs, with each job’s next run, last run and outcome. This is the page to check when something that should have happened overnight didn’t.
Editing safely
Editing a workflow doesn’t disturb instances that are already in flight; they finish under the definition they started with. Delete a workflow and it stops firing, but its history stays so you can still see what it did.
Workflow or worker?
| Use a workflow when | Use a worker when |
|---|---|
| The steps are always the same | Each run needs judgment |
| A person must approve something | Nobody needs to sign off |
| You need an audit trail per record | You need a summary or a decision |
| The trigger is a record changing | The trigger is a schedule or a question |
They combine well: a workflow step can hand a fuzzy sub-task to a worker, then continue with whatever the worker returns.
Next
- AI workers — the judgment half.
- Integrations — letting a step reach outside CogniWork.