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
  • Any built-in or custom field, through the same filter paths the dashboard uses
Conditions can be composed with AND or OR logic and nested arbitrarily.

​
Gate conditions

Four conditions exist specifically to express approval logic. See Reviews, approvals and gates for how these compose into all-of, any-of, threshold-based and sequential approval patterns.

​
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

Raise a review gate, generic or scoped to a risk domain

Update a review's status, outcome or notes

Create or update a work queue item

Create or update a finding, obligation, contract or engagement

Send an email, or a portal to a vendor

Create a Jira issue or a ServiceNow record

Fire a webhook to an external endpoint

​
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.
  • 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 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, using 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.