Skip to content

Workflow Templates

Where to find it: Administration, then Workflow Settings (/settings/workflow).

A workflow template defines the stages a governed object passes through, who acts at each, what transitions are available, and where segregation of duties applies.


Anatomy of a template

ElementPurpose
KeyThe template identifier
NameA human-readable description of the chain
Object typeWhat kind of record it governs
StagesThe ordered steps

Each stage carries:

ElementPurpose
Key and labelIdentity and display
AssigneeA fixed role, or a resolver
Bucket hintWhich Workbench bucket the stage projects into: work, review or terminal
TransitionsThe actions available and where each leads
SoD flagWhether segregation of duties applies at this stage

Assignee resolution

TypeBehaviour
RoleRoutes to whoever holds the named tenant RBAC role key
Resolver: ownerRoutes to the record's owner
Resolver: owner_department_headRoutes to the owner's department head

Role keys are strings your administrator controls

The workflow engine has no notion of what compliance_manager means. It routes to whoever holds that role key.

Renaming or remapping a role in your tenant changes who receives the stage, without any change to the template.


System templates

OrviQ seeds a set of system templates covering every governed object. They are tenant-editable.

Object typeTemplates
RequirementWork to Close; Work, Review, Close; Work, Department Review, Compliance Review, Close; Work, Department Review, Compliance Review, Management Approval, Close
FindingWork, Risk Review, Compliance Review, Close
PolicyDraft, Compliance Review, Published (four-eye); Draft, Compliance Review, Executive Sign-off, Published (six-eye)
ExceptionDraft, Review and Approval (four-eye); Draft, Risk Review, Senior Management Approval (six-eye)
Risk acceptanceRequest, Risk and Compliance Review, with escalation to Senior Management or CCO
ApplicabilityDraft, Independent Compliance Review, with escalation (four-eye); Draft, Compliance Review, Executive Sign-off (six-eye)
MappingDraft and Propose, Independent Mapping Review
Audit planDraft, Audit Review and Approval
Audit engagementFieldwork, Independent Audit Review, with escalation to Executive or CAE Sign-off
Regulatory inspectionDraft Response, Independent Compliance or Legal Review, with escalation to Executive or Committee
BIADraft, Risk and Continuity Review, with escalation to Business or Committee Approval
Continuity planDraft, Continuity Review, with escalation to Executive Approval
Resilience exerciseConduct, Independent Review and Sign-off, with escalation
Resilience assessmentAssess, Resilience Review and Sign-off
IncidentInvestigation and Remediation, Independent Review and Closure Sign-off, with escalation
Third-party engagementPrepare, Risk Review, with four decision outcomes

Bindings

A binding selects which template governs which object type, optionally by routing tier.

Object typeTierTemplate
requirement*Full four-stage chain with management sign-off
requirementtier_3Lighter Work, Review, Close chain
policy*Four-eye publication
exception*Four-eye approval

A tier binding does not force or skip stages mid-run

Bindings select the template at the point a workflow run starts. Changing a binding does not reshape a run already in progress.

This is deliberate: a decision part-way through a three-stage chain should not silently lose a stage because configuration changed.


Editing a template

Templates are tenant-editable. Before changing one:

  1. Understand what is in flight. Existing runs continue on the template they started with.
  2. Check role coverage. A stage bound to a role nobody holds routes nowhere.
  3. Check segregation actually holds. A chain where one person holds two consecutive stage roles has fewer eyes than it appears to.
  4. Record why. Approval chain changes are the kind of thing an auditor asks about.

Requires workflow.configure.


Terminal stages

A stage with a terminal bucket hint concludes the run. Reaching a terminal stage is what triggers the domain module to update its authoritative business state.

Intermediate approvals in a multi-stage chain advance the stage; they do not publish a policy, approve an exception or close an incident.


Permissions

ActionPermission
Define workflow steps and stagesworkflow.configure
Assign step responsibilityworkflow.assign
Approve transitionsworkflow.approve
Administrative overrideworkflow.override

workflow.configure is an administrative permission.


Example

A bank tightening its exception chain.

Before: all exceptions used the four-eye exception_review_approve template — draft, then review and approval by the Compliance Manager.

Trigger: an internal audit observation that exceptions on critical systems were being approved at the same level as routine ones.

After: a second binding was added so that exceptions on critical systems use the six-eye exception_review_mgmt_approve template — draft, then risk review, then executive or CCO approval.

Effects observed over the following quarter:

MetricFour-eyeSix-eye
Exceptions processed419
Median time to decision4 days11 days
First-time approval rate88%56%

The six-eye chain is slower and rejects more, which is the intended trade-off for the nine decisions that carry the most consequence. Applying it to all fifty would have added a week to every routine exception and produced pressure to avoid the process.

In-flight runs: the seven exceptions already in the four-eye chain when the binding changed completed on that chain. None silently gained or lost a stage.


Troubleshooting

"A stage routes to nobody." Its role binding names a role no user holds. Check role assignments.

"Changing a binding did not affect an in-flight approval." Correct. Runs complete on the template they started with.

"The chain has fewer people than stages." One person holds multiple stage roles. See Segregation of Duties.

"An approval did not update the business state." It was not the terminal stage.


OrviQ Enterprise Governance, Risk & Compliance Platform