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’s term running out (Contract.Expired), or a finding being raised. Every trigger in the picker is an event in the event catalog.
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.
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. 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 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. 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 action picker groups them by the record they act on:

Create, update, begin or complete an assessment

Create or send a portal, or send a custom portal, to a vendor

Begin or finalize an intake, or create or update an intake session

Create or update a vendor or service, update its status or relationship owners, or derive its tier

Enable Radar monitoring for a vendor, or update a Radar signal

Create or update a review: the review gate

Create or update a work queue item

Create or update a finding, risk, case, contract, engagement or procurement

Link documents to a record

Send an email

Create a Jira ticket

Create or update ServiceNow records, send a custom ServiceNow request, or upload documents to ServiceNow

Send a webhook to an external endpoint

Run another workflow, now or at a scheduled time, or update this workflow run

​
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 Send webhook action delivers the workflow’s triggering event to 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.
Every delivery from this action is recorded in delivery history. If there is no active webhook to deliver to, the step is skipped.
To start a workflow from outside the dashboard, run it by name through the API. See Triggering workflows from external systems.