Appearance
Enterprise Workflow
Where to find it: Work & Decisions (/my-work).
This domain is the connective layer that makes governance work: how OrviQ decides who must act, tells them, tracks whether they did, and records the decision.
The separation of concerns
The governing principle of the whole domain:
A business module requests governed approval. The canonical organisational workflow layer determines the stages, roles and segregation. The Workbench and Notifications route each stage. The final workflow decision updates the authoritative business state, which the domain module owns.
| Layer | Owns |
|---|---|
| Organisational workflow | Stage definitions, approval chains, role assignment, segregation of duties |
| Domain module | The final business state, operational invariants, entity validation |
Approval stages and four, six and eight-eye requirements are organisational policy, not module-specific business logic. That is why they are configured once and consumed by policies, exceptions, mappings, applicability decisions, incidents, audits, BIAs and everything else.
Three things that are not the same
| Event | Notification | Workbench task | |
|---|---|---|---|
| Means | Something happened | Someone may need to know | OrviQ is waiting for a specific person to act |
| Example | A collector run completed | An indicator moved to failing | A mapping needs your approval |
| Action required | None | Optional | Yes, by you |
| Blocks progress | No | No | Yes |
Automated events do not create Workbench tasks
A task is created only when OrviQ is genuinely waiting for a human being to do something. Sweeps, collector runs, indicator evaluations and freshness checks produce events, not tasks.
A Workbench full of machine activity is a Workbench nobody reads.
Articles
| Article | What it covers |
|---|---|
| Workbench | Your personal queue: buckets, deep links, ownership offers |
| Approvals Hub | The decision centre across all governed objects |
| Notifications | The notification bell, alerts and delivery |
| GRC Calendar | Governance obligations with dates, and what deliberately stays off it |
| Workflow Templates | System templates, stages, transitions and bindings |
| Multi-Eye Approvals | Four, six and eight-eye chains |
| Segregation of Duties | How SoD is enforced, and the governed break-glass |
| Decision History | The audit trail of every governed decision |
The human action rule
If OrviQ is waiting for a human user or role to act:
workflow state, then Workbench task, then notification, then deep link to the exact record and action, then authoritative action, then task completed and the next task created.
Every step in that chain is required. A workflow state with no task is invisible. A task with no deep link makes the person hunt for the record. A completed action that does not close the task leaves a permanently stale queue.
Related domains
Every governed domain consumes this layer:
- Regulatory & Compliance — applicability approval, compliance review
- Controls & Assurance — mapping approval, assessment review
- Risk & Remediation — risk acceptance, exception approval, action plan approval
- Policy Governance — publication approval, attestation
- Audit & Oversight — plan approval, engagement sign-off, response sign-off
- Operational Resilience — BIA, plan and exercise approval
- Incidents & Loss — closure review
- Third-Party Risk — engagement decisions