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.

Configure SLAs

An SLA sets how long a risk should remain in a state and when it becomes at risk.

  1. Open the SLA administration page.
  2. Choose the workflow state.
  3. Set the total days allowed.
  4. Set the at-risk threshold.
  5. Add rating-specific rules when needed.
  6. Save and confirm badges on a test risk.

Dashboard queues, digest email, and trend snapshots also depend on their feature switches and background jobs.

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 such as a notification, field update, webhook call, or Jira-related action.
  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.

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 can 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.