> ## 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 entering its renewal window, or an evaluation being flagged as a finding.
  </Accordion>

  <Accordion title="Schedule events" icon="calendar-clock">
    A workflow runs on a recurring schedule. Examples include quarterly reassessment of all critical vendors, annual SOC 2 refresh, or monthly checks for expiring contracts.
  </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.

Common patterns include:

* IRQ score above or below a threshold
* Data classification (PII, PHI, PCI, or none)
* Hosting model (SaaS, on-prem, or hybrid)
* Geographic jurisdiction
* Vendor tier or criticality
* Whether prior assessment evidence exists
* Whether a specific document type is present

Conditions can be composed with `AND` or `OR` logic and nested arbitrarily.

## Actions

Actions execute work. The available actions:

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

  <Card title="Send a questionnaire to a vendor contact" icon="paper-plane" />

  <Card title="Request specific evidence types" icon="file-arrow-up" />

  <Card title="Run Copilot against uploaded evidence" icon="robot" />

  <Card title="Run Inspect against a vendor's public surface" icon="magnifying-glass" />

  <Card title="Run Contract Guardian against an agreement" icon="file-contract" />

  <Card title="Transition a vendor or assessment lifecycle state" icon="arrow-right-arrow-left" />

  <Card title="Assign a task to an internal owner" icon="user-check" />

  <Card title="Wait for human review" icon="user-clock" />

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

### `send_webhook` action

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

* By default the event type is the workflow's triggering event; an optional **event type override** changes which subscriptions are matched and the type the delivery is labeled with.
* An optional **`webhook_ids`** restricts delivery to an explicit subset of the org's webhooks for that event type. Omit it to fan out to every active subscription for the event type.
* One shared `event_id` is generated per action invocation, so a receiver can dedupe a multi-webhook fan-out — 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 no active webhook is subscribed to the (possibly overridden) event type, the action is a no-op.

<Note>
  Every action that runs in the UI is also exposed as an API endpoint. Anything that can be configured as part of a workflow can also be invoked directly from outside the workflow engine.
</Note>