---
title: 09.07 Understanding SimpleRisk Workflows
description: "Two distinct things in SimpleRisk are called \"workflow\" — the built-in per-entity status lifecycles (risks, audits, incidents) and the Workflows Extra…"
---
[Skip to content](https://support.simplerisk.com/kb/09-07-understanding-simplerisk-workflows#main-content)
English
Show submenu for translations
[Customer portal](https://support.simplerisk.com/tickets?hsLang=en)
[](https://www.simplerisk.com/)
Open main navigation
Close main navigation
- English
Show submenu for translations
- [Customer portal](https://support.simplerisk.com/tickets)
- [Contact us](https://www.simplerisk.com/about-us/contact-us)
[Contact us](https://www.simplerisk.com/about-us/contact-us)
How can we help you?
- There are no suggestions because the search field is empty.
1. [SimpleRisk Knowledge Base](https://support.simplerisk.com/kb?hsLang=en)
2. [User Guide](https://support.simplerisk.com/kb/user-guide?hsLang=en)
3. [09 Day-to-Day SimpleRisk](https://support.simplerisk.com/kb/user-guide?hsLang=en#09-day-to-day-simplerisk)
# 09.07 Understanding SimpleRisk Workflows
## Two distinct things in SimpleRisk are called "workflow" — the built-in per-entity status lifecycles (risks, audits, incidents) and the Workflows Extra (custom event-driven automation). Here's the difference and when to reach for each.
## Why this matters
The word "workflow" gets used for two genuinely different things in SimpleRisk, and conflating them produces confused conversations. Knowing which is which is the prerequisite for any conversation about how a process gets implemented.
The two things:
- **Built-in entity workflows** are the *hardcoded status lifecycles* attached to each major entity type. A risk moves through New → Mgmt Reviewed → Mitigation Planned → Closed; an audit moves through Not Started → In Progress → Complete → Pass/Fail; an incident moves through Identification → Containment → Eradication → Recovery → Closed. These are baked into SimpleRisk's data model and code; they're not customizable, they're not optional, they don't have a configuration surface. They're how SimpleRisk represents "what state is this entity in?" at the application level.
- **The Workflows Extra** is an optional add-on that adds *custom event-driven automation*. Customers can define custom workflows (when X happens, send Y email or trigger Z action) with their own triggers, conditions, and actions. It's a programmable surface; it ships with sensible defaults but the customer authors what runs.
The two systems coexist. The built-in lifecycles handle the per-entity state machine; the Workflows Extra handles the cross-cutting "when something happens, also do this other thing" automation. Programs that need only standard SimpleRisk behavior get by on the built-in lifecycles alone; programs that need custom notifications, custom routing, custom escalations, or custom integrations install the Extra.
The other reason this matters: when you're trying to do something process-related and asking "is there a workflow for that?", the answer depends on which kind of workflow. The built-in lifecycles are baked in (there's no "create a new built-in workflow" path); SimpleRisk handles the state transitions for you, and customizing them requires source-code changes. The Workflows Extra is the customization surface; if you need custom event handling, that's where it lives.
## How frameworks describe this
Most major frameworks talk about "workflows" in the broader process-management sense rather than tying the term to specific tooling. The relevant framework references:
- **NIST SP 800-53** **PM-9** (Risk Management Strategy) and **PM-10** (Authorization Process) describe the workflows for risk and system authorization without prescribing specific implementations. The workflows are *processes* the program runs, not specific software flows.
- **NIST CSF v2.0** under **Govern** function describes the cyclical risk management workflow at a strategic level — the same identify-assess-treat-monitor-report loop covered in [The GRC Program Lifecycle](https://support.simplerisk.com/kb/00-02-the-grc-program-lifecycle?hsLang=en).
- **ISO/IEC 27001** clause **8** (Operation) describes operational planning and control as ongoing process, with documented procedures for the security operations the ISMS supports.
- **NIST SP 800-61** four-phase IR lifecycle (Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity) is itself a workflow — and one that SimpleRisk's Incident Management Extra implements explicitly. See [What is Incident Response?](https://support.simplerisk.com/kb/07-01-what-is-incident-response?hsLang=en).
The framework view is "your program runs workflows; how you implement them is up to you." SimpleRisk's split between built-in lifecycles and custom Workflows Extra is one implementation; other GRC tools take different approaches (configurable workflows from the start, no custom workflows at all, etc.).
## How SimpleRisk implements this
### The built-in entity workflows
Each major entity in SimpleRisk has its own status lifecycle. The lifecycles are hardcoded; the state transitions happen in response to user actions or programmatic API calls.
**Risk lifecycle:**
- **New** (status 1 in the underlying database) — risk submitted but not yet reviewed.
- **Mgmt Reviewed** — first management review has been submitted (see [Reviewing and Approving Risks](https://support.simplerisk.com/kb/01-04-reviewing-and-approving-risks?hsLang=en)).
- **Mitigation Planned** — a mitigation has been recorded (see [Mitigating a Risk](https://support.simplerisk.com/kb/01-05-mitigating-a-risk?hsLang=en)).
- **Closed** (with various closure reasons) — risk no longer active.
- **Reopened** — was closed, now reactivated.
The transitions happen automatically based on user actions (submitting a review changes status to Mgmt Reviewed; saving a mitigation changes status to Mitigation Planned). There's no "skip a state" path; the lifecycle progresses linearly through the actions that drive each transition.
**Audit / control test lifecycle:**
- States: **Not Started** → **In Progress** → **Complete** with final result **Pass** / **Fail** / **Inconclusive**.
- The transitions happen as the audit's actions are performed (see [Control Tests and Evidence Collection](https://support.simplerisk.com/kb/02-07-control-tests-and-evidence-collection?hsLang=en)).
**Incident lifecycle (with Incident Management Extra):**
- The Extra implements NIST 800-61's four phases as the incident's status: New (status 1) → Containment (2) → Eradication (3) → Recovery (4) → Closed (statuses 5–11 with various closure reasons). See [The Incident Management Extra](https://support.simplerisk.com/kb/07-03-the-incident-management-extra?hsLang=en).
**Document exception lifecycle:**
- Created → Unapproved → Approved (and back to Unapproved when updated, per the load-bearing rule documented in [Exceptions Management](https://support.simplerisk.com/kb/03-03-exceptions-management?hsLang=en)).
**Document lifecycle:**
- Status values typically include Draft → In Review → Approved → Retired, configurable per install.
These built-in workflows are part of SimpleRisk's behavior; you don't configure them, you operate against them. The user-facing surface for each is the entity's detail view, where the appropriate action button (Save Review, Save Mitigation, Approve Exception, etc.) drives the next state transition.
### The Workflows Extra
The **Workflows Extra** lives at `simplerisk/extras/workflows/` and is an admin-installed, admin-activated capability for *custom* workflow automation. The Extra's data model includes:
- **Workflow definitions** — the workflows your organization has authored, each with its triggers, conditions, and actions.
- **Email templates** — the templates workflows use for notification actions, written with ``-style substitution.
Two types of workflows live in the Extra:
- **System workflows** (system workflows) — seeded on Extra activation. The Extra ships with at least one default workflow (a "New Risk Submitted" workflow that fires when a risk is created and sends a notification email using the seeded template). System workflows can be edited but aren't deleted when the Extra is deactivated.
- **Custom workflows** (your own workflows) — authored by the customer. These are deleted when the Extra is deactivated (the schema remains; the data is cleared).
What customers build with the Workflows Extra:
- Custom notification routing — emails to specific people based on entity attributes (e.g., "if a risk's category is 'Privacy', also notify the privacy officer").
- Custom field updates — automatically populate or modify fields based on triggering events.
- Custom escalations — recurring notifications to managers when items remain in a particular state too long.
- Integration triggers — fire calls to external systems via custom action handlers.
The Workflows Extra and the Notification Extra (covered in [Notifications and Email Preferences](https://support.simplerisk.com/kb/09-05-notifications-and-email-preferences?hsLang=en)) overlap: both can send emails on events. The distinction is configurability — the Notification Extra has a fixed set of events and routing rules with simple toggles; the Workflows Extra is open-ended and lets customers author whatever logic they need.
For installations running both Extras, the operational pattern is usually: the Notification Extra handles the standard notifications (the predictable per-event sends to standard roles), and the Workflows Extra handles the specific custom logic that doesn't fit the Notification Extra's templates.
## Common pitfalls
A handful of patterns recur with workflow understanding.
- **Conflating "workflow" with "the Workflows Extra."** The most common confusion. A user asking "how do I customize the risk workflow?" might mean "how do I customize the risk lifecycle states?" (answer: you can't, it's hardcoded) or "how do I add custom automation to the risk submission?" (answer: use the Workflows Extra). Clarify which kind of workflow before reaching for an answer.
- **Trying to skip built-in workflow states.** The risk lifecycle goes through Mgmt Reviewed before Mitigation Planned. A user who wants to plan a mitigation on an unreviewed risk can't directly skip the review state. The workaround is either to do the review (recommended), or to configure the install in a way that bypasses the review requirement (admin setting that may exist depending on version), or to live with the state machine.
- **Building custom workflows for capabilities the Notification Extra already covers.** A Workflows Extra workflow that "sends an email when a new risk is submitted" duplicates what the Notification Extra's `NOTIFY_ON_NEW_RISK=true` already does. Use the simpler tool when the simpler tool suffices; reserve the Workflows Extra for genuinely custom logic.
- **Authoring workflows without testing.** A workflow that fires on every new-risk event and runs custom logic may produce unexpected results in production. Test workflows on test data first; deactivate them quickly if they misbehave; iterate.
- **Forgetting that the Workflows Extra deactivation deletes custom workflows.** Deactivation is destructive for custom-authored workflows; the schema persists but the data is cleared. Back up workflow definitions before deactivating the Extra.
- **Not coordinating workflow customization with the Notification Extra's settings.** Both Extras can send emails on events. A program with both running may produce two emails for the same event — one from the Notification Extra and one from the Workflows Extra workflow. Coordinate to avoid duplicates; either disable the Notification Extra event for cases the Workflows Extra workflow handles, or have the Workflows Extra workflow check whether the Notification Extra has already fired (which requires custom action logic).
- **Treating the built-in workflow states as configurable enums.** The status enum on each entity (the integer values that map to "New", "Mgmt Reviewed", etc.) is hardcoded. Customizing the labels for the existing states is sometimes possible via admin configuration; *adding* new states or removing existing ones requires source-code changes and isn't supported.
- **Writing workflow templates with placeholder typos.** The Workflows Extra's email templates use `` syntax. A typo'd placeholder (e.g., `` instead of ``) results in literal placeholder text appearing in sent emails. Test templates by triggering test events and reading the resulting emails; check for unsubstituted placeholders.
## Related
- [Navigating the UI](https://support.simplerisk.com/kb/09-01-navigating-the-ui?hsLang=en)
- [Notifications and Email Preferences](https://support.simplerisk.com/kb/09-05-notifications-and-email-preferences?hsLang=en)
- [Reviewing and Approving Risks](https://support.simplerisk.com/kb/01-04-reviewing-and-approving-risks?hsLang=en) (for the risk-lifecycle states in detail)
- [Control Tests and Evidence Collection](https://support.simplerisk.com/kb/02-07-control-tests-and-evidence-collection?hsLang=en) (for the audit lifecycle)
- [The Incident Management Extra](https://support.simplerisk.com/kb/07-03-the-incident-management-extra?hsLang=en) (for the incident lifecycle structured around NIST 800-61)
- [Exceptions Management](https://support.simplerisk.com/kb/03-03-exceptions-management?hsLang=en) (for the exception approval state machine)
- [The GRC Program Lifecycle](https://support.simplerisk.com/kb/00-02-the-grc-program-lifecycle?hsLang=en) (for the program-level workflow concept)
- [FAQs](https://support.simplerisk.com/kb/faqs?hsLang=en)
- [SimpleRisk Extras](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#main-content)
- [Vulnerability Management Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#vulnerability-management-extra)
- [Team Separation Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#team-separation-extra)
- [Import-Export Extra](https://support.simplerisk.com/kb/simplerisk-extras?hsLang=en#import-export-extra)
- [Administrator Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#main-content)
- [00 About This Guide](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#00-about-this-guide)
- [01 Installation and Deployment](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#01-installation-and-deployment)
- [02 Upgrades and Maintenance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#02-upgrades-and-maintenance)
- [03 Users and Permissions](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#03-users-and-permissions)
- [04 Authentication](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#04-authentication)
- [05 Customization](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#05-customization)
- [06 Configuring Risk and Compliance](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#06-configuring-risk-and-compliance)
- [07 Integrations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#07-integrations)
- [08 The API](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#08-the-api)
- [09 Encryption and Data Security](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#09-encryption-and-data-security)
- [10 Workflows and Automation](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#10-workflows-and-automation)
- [11 Reporting and Auditing](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#11-reporting-and-auditing)
- [12 Operations](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#12-operations)
- [13 Reference](https://support.simplerisk.com/kb/administrator-guide?hsLang=en#13-reference)
- [User Guide](https://support.simplerisk.com/kb/user-guide?hsLang=en#main-content)
- [00 Foundations of GRC](https://support.simplerisk.com/kb/user-guide?hsLang=en#00-foundations-of-grc)
- [01 Risk Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#01-risk-management)
- [02 Compliance Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#02-compliance-management)
- [03 Governance](https://support.simplerisk.com/kb/user-guide?hsLang=en#03-governance)
- [04 Asset and Data Inventory](https://support.simplerisk.com/kb/user-guide?hsLang=en#04-asset-and-data-inventory)
- [05 Threat and Vulnerability Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#05-threat-and-vulnerability-management)
- [06 Assessments](https://support.simplerisk.com/kb/user-guide?hsLang=en#06-assessments)
- [07 Incident Management](https://support.simplerisk.com/kb/user-guide?hsLang=en#07-incident-management)
- [08 Audit and Reporting](https://support.simplerisk.com/kb/user-guide?hsLang=en#08-audit-and-reporting)
- [09 Day-to-Day SimpleRisk](https://support.simplerisk.com/kb/user-guide?hsLang=en#09-day-to-day-simplerisk)
- [10 Continuous Improvement](https://support.simplerisk.com/kb/user-guide?hsLang=en#10-continuous-improvement)
- [SimpleRisk User Guides](https://support.simplerisk.com/kb/simplerisk-user-guides?hsLang=en)
- [Troubleshooting](https://support.simplerisk.com/kb/troubleshooting?hsLang=en)
- [SimpleRisk Hosted](https://support.simplerisk.com/kb/simplerisk-hosted?hsLang=en)
- [How To videos](https://support.simplerisk.com/kb/how-to-videos?hsLang=en)
[](https://www.simplerisk.com)
Copyright © 2026, SimpleRisk, Inc.