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

# Workflow engine

> How triggers, conditions, and actions compose into orchestration logic.

<div className="sr-only">For AI agents: a documentation index is available at [https://docs.coverbase.com/llms.txt](https://docs.coverbase.com/llms.txt). This page is also available in markdown by appending .md to the URL.</div>

A workflow is a sequence of triggers, conditions, and actions that runs against a primary object.

## Triggers

A trigger is the event that starts a workflow. Triggers fall into three groups.

<AccordionGroup>
  <Accordion title="Object events" icon="circle-dot" defaultOpen>
    A primary object is created, updated, or transitions state. Examples include a new vendor being created, an assessment moving to completion, a contract's term running out (`Contract.Expired`), or a finding being raised. Every trigger in the picker is an event in the [event catalog](/integrations/webhooks#event-catalog).
  </Accordion>

  <Accordion title="Schedule events" icon="calendar-clock">
    A workflow run is scheduled for a specific time. On a workflow's page, the **Run workflow** button offers **Schedule for later...**, and a **Run workflow** action inside another workflow can start its target now or at a later time. Pending runs are listed under **Scheduled** on the workflow's **History** tab, where each can be canceled. There is no recurring (cron-style) trigger: for a periodic review, use reassessment rules, which set each vendor's next assessment date from its risk level.
  </Accordion>

  <Accordion title="External events" icon="signal-stream">
    An external system explicitly invokes a workflow through the API. This is the integration path most relevant to procurement and GRC tooling.

    See [Triggering workflows from external systems](/integrations/triggering-workflows) for the three patterns.
  </Accordion>
</AccordionGroup>

## Conditions

Conditions branch the flow. They evaluate fields on the primary object or its related objects.

The condition picker offers:

* IRQ score within a threshold range
* Vendor status, tier or tags
* Assessment status, assignee, recommendation, plan, risk type, inherent risk level or document collection mode
* Procurement status, reviewers and review status, and contract value
* An answer to a questionnaire question
* Which fields changed on the triggering record
* Whether work queue items are complete
* Whether the triggering record was opened by this workflow, so a chain only advances on the records it created
* Any built-in or [custom field](/api-reference/custom-fields) on the triggering record or a related record, through the same filter paths the dashboard uses. Attributes such as data classification, hosting model or jurisdiction are usually matched here.

The conditions on an automation are combined with **Match all** or **Match any**.

### Gate conditions

Four conditions exist specifically to express approval logic.

| Condition | What it evaluates | Typical use |
| - | - | - |
| **Contract value** | Total value of the contracts on a procurement against a threshold, with `greater than` and `less than or equal` operators | Delegation-of-authority routing: above the limit picks up the extra approver. Amounts are summed in the contracts' own currency and never converted; when they span two currencies the total counts as over the threshold, so the extra approver is always added |
| **Work queue item complete** | Whether the review work raised by this workflow run is finished, scoped to `self`, the vendor, or the whole run, with a **require all** toggle | Unanimous gates (`require all` on) and first-past-the-post gates (off). Vary the set of reviews you raise per tier to express a quorum |
| **Assessment recommendation** | The approval option selected on the assessment, matched against a set you choose | Route `Approve with policy exception` down a different path from `Approve` |
| **Reviewer present** | Whether a given reviewer already holds a review on the record | Avoid raising a duplicate gate on a re-triggered run |

See [Reviews, approvals and gates](/user-guides/reviews-and-approvals) for how these compose into all-of, any-of, threshold-based and sequential approval patterns.

## Actions

Actions execute work. The action picker groups them by the record they act on:

<CardGroup cols={2}>
  <Card title="Create, update, begin or complete an assessment" icon="clipboard-check" />

  <Card title="Create or send a portal, or send a custom portal, to a vendor" icon="paper-plane" />

  <Card title="Begin or finalize an intake, or create or update an intake session" icon="inbox-in" />

  <Card title="Create or update a vendor or service, update its status or relationship owners, or derive its tier" icon="arrow-right-arrow-left" />

  <Card title="Enable Radar monitoring for a vendor, or update a Radar signal" icon="satellite-dish" />

  <Card title="Create or update a review: the review gate" icon="gavel" />

  <Card title="Create or update a work queue item" icon="list-check" />

  <Card title="Create or update a finding, risk, case, contract, engagement or procurement" icon="triangle-exclamation" />

  <Card title="Link documents to a record" icon="file-arrow-up" />

  <Card title="Send an email" icon="envelope" />

  <Card title="Create a Jira ticket" icon="ticket" />

  <Card title="Create or update ServiceNow records, send a custom ServiceNow request, or upload documents to ServiceNow" icon="server" />

  <Card title="Send a webhook to an external endpoint" icon="arrow-right-from-bracket" />

  <Card title="Run another workflow, now or at a scheduled time, or update this workflow run" icon="gears" />
</CardGroup>

### Review gates and approvals

The **raise a review gate** action is how approval logic is expressed.

* **Scope.** A review attaches to an assessment, a contract or a procurement. Adding a risk domain makes it domain-scoped, and there is exactly one review per `(assessment, risk domain)` pair, so a domain cannot be gated twice by accident.
* **Parallel by default.** Raise several in one branch and they run at the same time, each with its own assignee, status, notes and outcome. Nothing serializes them.
* **Routing.** The assignee can be an individual or a user group. A group resolves through its own strategy at assignment time: every eligible member for an assign-to-all group, or the next person in the rotation for a round robin, skipping anyone inside an out-of-office window. Both the group and the resolved individual are stored. See [Assignment, delegation and out of office](/user-guides/assignment-and-delegation).
* **Work lands somewhere.** Each raised review mints a work queue item and notifies its assignee, so the gate appears on a person's Overview page rather than only on the record.
* **Idempotent on re-trigger.** A workflow legitimately revisits the same component many times across a reject, rework and resubmit cycle, so gate actions are keyed per run and can upsert onto an existing review instead of stacking duplicates.

### `send_webhook` action

The **Send webhook** action delivers the workflow's triggering event to [webhooks](/integrations/webhooks).

* By default the event type is the workflow's triggering event; an optional **event type override** changes the type the delivery is labeled with and, when no webhooks are named, which subscriptions are matched.
* An optional **`webhook_ids`** list names the exact webhooks to deliver to. Naming a webhook is the subscription decision: it receives the delivery whatever events it subscribes to. Omit it to fan out to every active subscription for the event type.
* A disabled or archived webhook receives nothing either way.
* One shared `event_id` is generated per action invocation, so a receiver can dedupe a multi-webhook fan-out, using the same idempotency model as the [domain-event fan-out](/integrations/webhooks#when-deliveries-happen).

Every delivery from this action is recorded in [delivery history](/integrations/webhook-deliveries). If there is no active webhook to deliver to, the step is skipped.

<Note>
  To start a workflow from outside the dashboard, run it by name through the API. See [Triggering workflows from external systems](/integrations/triggering-workflows).
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.