Skip to main content
For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt — this page is also available in markdown by appending .md to the URL.
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.

Object events

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.
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.
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 for the three patterns.

​
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:

Create or update an assessment

Send a questionnaire to a vendor contact

Request specific evidence types

Run Copilot against uploaded evidence

Run Inspect against a vendor's public surface

Run Contract Guardian against an agreement

Transition a vendor or assessment lifecycle state

Assign a task to an internal owner

Wait for human review

Fire a webhook to an external endpoint

​
send_webhook action

The Fire a webhook action delivers the workflow’s triggering event to subscribed 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.
Every delivery from this action is recorded in delivery history. If no active webhook is subscribed to the (possibly overridden) event type, the action is a no-op.
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.