Workflow, SLAs, and automation

Administrators can shape the lifecycle, set time targets, and automate repeatable actions. These changes affect day-to-day work across the organization, so validate them in a controlled environment and document the reason.

Change the workflow

The Workflow Designer can enable or disable states, define transitions, set required claims, control editable fields, and set prerequisites.

  1. Open Administration > Workflow Designer.
  2. Review the current diagram before changing anything.
  3. Select the state or transition to change.
  4. Update its availability, destination, required permission, editable fields, or required fields.
  5. Save the draft configuration.
  6. Test with representative creator, analyst, approver, and view-only accounts.
  7. Confirm both successful and rejected transitions.
  8. Activate according to your change-control process.

Image needed: Workflow Designer diagram with one state, one transition, and the field-permission editor labeled.

Change action wording

The Action Wording button on the Workflow Designer page lets you change the wording people see on workflow action buttons and confirmation dialogs: the button label, the confirmation title and message, and the labels on any fields the action collects, such as a rejection reason.

Action Wording has its own permission, separate from the rest of workflow design, so it can be given to someone who should change wording but not behavior. Reset to default on any field restores RiskVault's built-in wording as it currently stands. If that default changes in a later release, a field you reset picks up the new wording automatically.

Reviewer assignment and self-review

Two behaviors live on the Workflow Settings page, separate from the Workflow Designer:

  • Automatic reviewer assignment — when on, a newly submitted risk is handed to a reviewer immediately, rotating round-robin among everyone who has all four reviewer abilities: reviewing, proposing within tolerance, assessing outcomes, and reopening. With the standard policies, that means people with the Admin, Risk Analyst, or Executive Approver (Risk Committee) policy. The Risk Reviewer policy alone isn't enough, because it can't reopen risks.
  • Block creators from reviewing their own risks — off by default, so anyone with review permission can validate, reject, or request more information on any risk they can see, including their own. Turn it on to require a second pair of eyes: the creator of a risk can then no longer make those decisions on it.

Configure SLAs

An SLA is a deadline for how long a risk should stay at a given step. Manage SLAs under Administration > SLA Config, which needs the Manage SLAs permission (Admin and Risk Manager by default).

Each SLA rule has:

  • a workflow state — the step it times, such as Under Review;
  • a risk rating, or Any rating;
  • the SLA days — calendar days, not business days, the risk may stay in that step;
  • the at-risk threshold — how many days before the deadline to start warning.

Image needed: SLA Config list showing a state's Any rating rule followed by its rating exceptions, with Edit, Suspend, and Delete actions.

Any rating rules and rating exceptions

A step can have one Any rating rule plus rules for specific ratings. They work as a default with exceptions:

  • A rule for the risk's own rating always wins.
  • Otherwise the Any rating rule applies. It also covers unrated risks, which makes it the right choice for review turnaround: risks are usually scored during review, so a rating-specific Under Review rule wouldn't apply to most of them yet.
  • The list shows each step's Any rating rule first, followed by its rating exceptions from the highest band down.

For example, Treatment Planning with "Critical: 2 days" and "Any rating: 10 days" gives Critical risks 2 days and every other risk, rated or not, 10 days.

When the clock starts

A risk's SLA clock starts when it enters a step, and its deadline is the entry time plus the rule's days. For Under Review, the clock starts when a reviewer is assigned, so time waiting in Submitted doesn't count. If a reviewer requests more information and the risk returns to Under Review, that is a new entry with a new clock.

The rule is chosen when the clock starts and stays fixed for that step, including its at-risk warning window. If a reviewer scores a risk Critical halfway through review, its deadline and warning date don't move; switching to a stricter rule then could breach the risk the moment it was scored. Both change only when the risk changes step or an administrator changes the SLA rules.

Change, suspend, resume, or delete a rule

Every change applies immediately to risks already in that step, not only to future ones. The confirmation dialog tells you how many risks are affected.

Change Effect on risks already in the step
Edit the days Each deadline is recalculated from when that risk's clock started. A risk 2 days into a 3-day review that moves to 5 days gets 3 more days, not a fresh 5. An overdue risk now inside the new deadline stops being overdue. If a shorter SLA pushes a risk past due, the hourly SLA check flags it and sends the usual overdue notice.
Suspend The rule stops applying. Affected risks lose their deadline and overdue flag, so they show no SLA badge and produce no digest entries or breach notices. A suspended rating-specific rule does not fall back to the Any rating rule. You can still edit a suspended rule; the values take effect when you resume it.
Resume Every affected risk gets a fresh deadline counted from the moment you resume, so nothing breaches the instant the SLA returns. Later edits to the days count from that resume time.
Create a rule for a step that already has risks Those risks get a deadline counted from now.
Delete a rating-specific rule Its risks fall back to an active Any rating rule, measured from when their clock started. With no active Any rating rule, they have no SLA. Delete, rather than suspend, when you want a rating to use the default again.

Each change is written to the audit log with the old and new values and the number of risks updated.

When no SLA applies

If no active rule covers a risk — none exists for its step, the rule is suspended, or the risk is unrated and the step has only rating-specific rules — the risk has no SLA. That isn't a warning: the SLA Status column shows a dash, and no badge, digest entry, or overdue flag appears.

Where SLAs show up

Badges, dashboard queues, digest email, and trend snapshots depend on their feature switches and background jobs being on.

The at-risk threshold also decides when an item enters the Due soon band in My Work Items. When no SLA applies, My Work Items uses a fixed three-day window instead.

Create a workflow rule

  1. Open Workflow Rules and create a rule or start from a template.
  2. Choose a trigger, such as a state change or external event.
  3. Build conditions using all, any, and not groups.
  4. Add actions: send an email or in-app notification, add a comment, write an audit-log entry, call a webhook, or record a compliance snapshot.
  5. Test against sample risks.
  6. Review integrations, referenced records, secrets, and endpoints required at run time.
  7. Save and enable the rule.
  8. Monitor its first real executions.

Rules can be cloned, disabled, edited, and deleted. A valid-looking rule can still fail later if a dependency is unavailable.

Rules that update fields

Only rules triggered by an inbound webhook (On External Event) can copy values from the incoming message into a risk, and only into a fixed set of fields: title, description, source of risk, source of identification, custom tags, likelihood and impact scores, initial risk level estimate, region, impact area, business unit, and risk factor. Rules triggered by an ordinary workflow step can't set fields.

Incoming text is stripped of formatting and markup. Scores outside your risk matrix are ignored, and a valid score change recalculates the rating. A field locked at the risk's current step is skipped. Every change is kept in the risk's version history and the audit log (see Inbound webhooks).

Choose who a rule's email or notification reaches

Each recipient in a Send Email or Send Notification action is one of:

Recipient Who it reaches
owner, reviewer, creator That person on the risk when the rule fires, so reassigning the risk changes who hears.
triggeredBy The person whose action set the rule off.
role:Name Everyone who currently holds that role, for example role:Risk Manager.
An email address A shared or external mailbox. Email only; in-app notifications need an account.

Deactivated and locked-out accounts are skipped, and each person receives one copy even if they match more than one entry.

Call a webhook from a rule

  1. Create the outbound endpoint first under Integrations.
  2. Add the Call Webhook action to the rule.
  3. Select the endpoint or enter its exact key.
  4. Add an event-type label when the receiver uses one.
  5. Build the JSON body template from allowed risk values.
  6. Test, save, and enable the rule.

A missing, disabled, or wrong-environment endpoint is skipped. Check the endpoint list and Webhook Monitor when no delivery appears.

Understand rule triggers and conditions

Choose the narrowest trigger that reflects the business event. Then use condition groups to prevent unnecessary runs.

For example, a rule that alerts on a Critical risk entering Treatment should combine the relevant state-change trigger with a rating condition. An all group requires every child condition; an any group needs one; not reverses the contained result.

Before enabling, test a matching risk, a near-match that should not run, and a record the rule creator cannot access.

Understand the execution identity

Automation does not run outside authorization. Connected inbound events run as the person who created the channel, and other automation uses the identity and rules defined by the application. If that account becomes inactive or loses record access, an otherwise correct rule can stop acting on a risk.

Document service ownership and avoid tying long-lived automation to a person likely to leave the responsibility without a handover.

Pause and revise safely

  1. Disable the rule before making a high-impact change.
  2. Review recent executions and failures.
  3. Clone the rule when you need a safe comparison or replacement.
  4. Change one logical concern at a time.
  5. Retest matching and non-matching records.
  6. Enable the revised rule and monitor early executions.

Monitor failures

Check rule history, risk activity, notifications, and the relevant integration monitor. Common causes include a disabled endpoint, expired or rotated secret, missing referenced record, invalid JSON template, deactivated execution user, changed permission, or state that no longer permits the intended action.

Do not repeatedly replay an action until you know whether the receiving system uses the event ID or idempotency key to reject duplicates.

Workflow change checklist

Before activating a workflow change, confirm:

  • every enabled state has an intended entry and exit path;
  • transitions lead to the expected phase and state;
  • required claims exist in the intended policies;
  • editable and required fields do not contradict one another;
  • creators, reviewers, owners, approvers, and view-only users see the correct actions;
  • existing in-flight risks still have a valid route forward;
  • SLAs, rules, notifications, reports, and integrations that reference changed states were reviewed;
  • support documentation and user communication are ready.