How Workflows Work in SAS Model Risk Management

Why Workflows Matter

Imagine two organizations managing hundreds of models.

The first organization relies on emails, spreadsheets, and manual reminders to move models through development, validation, approval, and production.

The second organization uses structured workflows that automatically guide users through every step of the model lifecycle.

Which organization is more likely to maintain consistent governance, meet regulatory requirements, and reduce operational risk?

For most organizations, the answer is obvious.

Workflows are the backbone of model governance. They define how work moves through your organization, who performs each activity, and what conditions must be met before the next step can begin.

In SAS Model Risk Management (MRM), workflows help ensure that every model follows an approved governance process from initial registration through retirement.

Before administrators begin building or modifying workflows, it's important to understand the architecture that makes workflow-driven governance possible.

In this post, we'll explore the key components that power workflow-driven governance in SAS Model Risk Management and build the foundation you'll need for designing, managing, and troubleshooting workflows.

Four Components Working Together

When people first open a workflow definition within SAS Workflow Manager, they often see diagrams, tasks, buttons, and templates and wonder how everything fits together.

The workflow architecture within the UI looks complex but it's simpler than it looks.

SAS Workflow Manager

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Every workflow process is built around four key components:

Business Objects
Workflow Definitions
Workflow Templates
Workflow Instances

Once you understand how these pieces interact, nearly every workflow administration task becomes easier to understand.

Business Objects: The Thing You're Managing

Let's begin with the easiest concept.

A business object is simply the item moving through the governance process.

In SAS MRM, business objects might include:

Models
Model Reviews
Findings
Change Requests
Model Candidate Assessments
Action Plans

Think of a business object as the "thing" that needs work performed on it.

The workflow itself doesn't exist for its own sake. It exists to guide that object through a process.

If you imagine an airport, the business object is the passenger. Everything else exists to help that passenger reach the destination.

Workflow Definitions: The Blueprint

Now let's talk about the process itself. A workflow definition is the blueprint for how work should happen.

It defines:

Tasks
Decisions
Transitions
Approvals
Notifications
Completion criteria

For example, an action plan lifecycle workflow might look something like this to the end user:

Action Plan workflow diagram

Behind the scenes, it may look something like this:

workflow diagram nodes

The workflow definition answers an important question:

"If everything goes according to plan, what path should this object follow?"

It does not represent an actual running process.

It's simply the design.

Think of it like a house blueprint.

You can build hundreds of houses from the same blueprint.

Workflow Instances: The Living Version of the Blueprint

This is where many new administrators become confused.

A workflow definition is not the same thing as a workflow instance.

A workflow instance is created when a workflow actually starts, i.e when you start a workflow within SAS MRM.

Control object page within SAS Model Risk Management

Imagine your organization has three models:

Credit Risk Model
Fraud Detection Model
Customer Attrition Model

All three models might use the exact same workflow definition.

But once the workflows start, each model has its own workflow instance.

In progress workflow instances

After opening a workflow instance, you can see exactly where a user is in the workflow process:

In progress workflow instance for Control object

Each instance maintains:

Its own status
Its own task history
Its own approvals
Its own audit trail

Why is this important?

Because updating a workflow definition does not automatically update workflow instances that are already running.

Understanding this distinction becomes incredibly important later when administrators begin upgrading workflows or moving to newer workflow versions.

Static Workflows vs. Dynamic Workflows

One of the most important concepts to understand in SAS Model Risk Management is the difference between static and dynamic workflows. This distinction is a key topic because it affects how workflows are assigned, updated, and maintained.

Static Workflows: One Process for Everyone

A static workflow means that a single workflow definition is registered to an object type at a time.

When a user starts a workflow for an object instance, SAS MRM automatically uses the latest enabled version of that workflow definition. Users do not select a workflow because there is only one process available for that object type.

Think of it as a one-lane road:

Object
   ↓
Workflow Definition

Every object follows the same path.

This approach works well when all objects require the same governance process and there is no need for workflow variation.

As of SAS MRM version 2026.02, the following out-of-the-box object pages use static workflows:

Non-Model
Model Candidate Assessment
Change Request
Model Attestation
Inventory Attestation
Finding*

From an administrator's perspective, static workflows are easier to manage because only one workflow definition must be maintained. The tradeoff is reduced flexibility when different business processes are needed for the same object type.

*Finding Objects: A Special Case

Although Finding objects use a static workflow out of the box, they support dynamic workflows.

Administrators can enable dynamic workflow support by configuring (SAS Risk Cirrus Builder > Page Configuration):

Findings.workflowTemplate.hidden = false

Findings.workflowTemplate.required = true

This allows findings to leverage workflow templates in the same way as other dynamic workflow-enabled objects.

Dynamic Workflows: Flexibility When You Need It

What happens when one process isn't enough?

Many organizations need different governance processes for different types of objects. For example, a bank may have separate processes for:

Traditional models
AI models
High-risk models
Low-risk models
Annual reviews
Full-scope validations

As organizations evolve, their governance processes evolve as well. New regulations, changing business requirements, and internal policy updates often require organizations to modify existing workflows or introduce entirely new ones.

Consider the following examples:

Scenario 1: New Workflow Definition

An organization currently uses a single Model Lifecycle Workflow for all models. As AI governance requirements mature, the organization decides that AI models should follow a different governance process than traditional models.

To support this change, administrators create a new AI Model Workflow with its own workflow definition. The organization now wants its existing AI models to use the new AI workflow, while traditional models continue using the original workflow.

This is an example of introducing a new workflow definition for a subset of objects.

Scenario 2: New Workflow Version

An organization has 100 models currently running version 1 of its Model Lifecycle Workflow. A new regulation requires an additional approval step before models can be deployed to production.

To address the requirement, administrators update the existing workflow definition and activate version 2. They now want the 100 models that are currently running version 1 of the workflow to begin using version 2.

This is an example of updating an existing workflow definition and transitioning active objects to a newer workflow revision.

What Are Dynamic Workflows?

If your organization uses multiple workflow definitions for the same object type, then dynamic workflows are typically the best choice.

Dynamic workflows allow multiple workflow definitions to be associated with a single object type. Rather than creating one massive workflow that attempts to handle every possible business scenario, organizations can create several smaller workflows that are optimized for specific use cases.

For example, you might create:

A workflow for traditional models
A workflow for AI models
A workflow for high-risk models
A workflow for low-risk models

Similarly, you might create different workflows for annual model reviews, targeted reviews, and full-scope validations.

This approach makes workflows easier to understand, maintain, test, and upgrade over time.

How Dynamic Workflows Work

Dynamic workflows use workflow templates.

Instead of registering a workflow definition directly to an object type, each object instance is linked to a workflow template instance.

Object
↓
Workflow Template
↓
Workflow Definition

For example, instead of building one enormous workflow with dozens of branches and decision points, an organization could maintain separate workflows for:

Standard model governance
AI model governance
High-risk model governance

Workflow Templates in SAS Model Risk Management

Default Workflow Templates

Most out-of-the-box pages that support dynamic workflows include a configuration property that allows administrators to specify a default workflow template.

When a user creates a new object instance:

If a default template exists, the object is automatically linked to that template.
If no default template exists, the user must select a workflow template before starting the workflow.
If the configured default template cannot be found, the user must select a template manually.

This provides flexibility while minimizing the amount of configuration required by end users.

Default Workflow Objects in SAS MRM

As of the 2026.02 version of SAS MRM, the following out-of-the-box object pages use dynamic workflows:

Model*
Model Review
Policy
Policy Exception
Control
Risk
Action Plan

*Model Objects: A Special Case

Although Model objects utilize dynamic workflows out of the box, they can be configured to use a static workflow instead.

Administrators can disable dynamic workflow support by setting:

Models.mrm_dynamicWorkflow.enabled = false

When this setting is disabled, models behave like a static workflow object, with a single workflow definition governing all model instances.

Most organizations continue using dynamic workflows because they support multiple model governance processes, such as separate workflows for traditional models, AI models, or models with different risk profiles.

So how does SAS Model Risk Management know which workflow definition to use for each object?

The answer lies in workflow templates.

Workflow Templates: The Hidden Hero

When administrators first learn workflows, they usually focus on workflow definitions.

But workflow templates are often the real heroes behind dynamic workflow management.

Without workflow templates, organizations would have difficulty supporting multiple governance processes for the same object type.

Workflow templates provide the flexibility needed to:

Support multiple workflow definitions
Separate AI and non-AI governance processes
Introduce new workflows without redesigning object types
Simplify workflow maintenance
Migrate objects between workflow definitions when business requirements change

Think of workflow templates as the layer that makes dynamic workflows possible.

Showing dynamic workflow for Model object

You can switch the template to another template for that same object.

Changing a workflow template

Workflow templates play a critical role when administrators need to migrate existing objects to new workflow definitions or newer workflow versions. Many workflow administration activities involve updating the workflow templates associated with existing object instances so they can begin using newer governance processes.

Why Organizations Are Moving Toward Dynamic Workflows

Business processes become harder to manage as organizations grow.

Imagine building one workflow to support:

AI Models
Traditional Models
High-Risk Models
Low-Risk Models
Annual Reviews
Full-Scope Validations

Eventually you end up with a workflow diagram that resembles a bowl of spaghetti.

Instead, organizations can create smaller, focused workflows.

The result is:

Easier maintenance
Clearer diagrams
Simpler testing
Better governance

This is a primary advantage of dynamic workflow design.

Bringing Everything Together

Let's follow the lifecycle of a model through the workflow architecture.

Suppose a model owner registers a new model in SAS Model Risk Management.

The model itself is the business object.

If the organization is using a static workflow, the model is automatically governed by the workflow definition registered to the model object type.

Model
↓
Workflow Definition
↓
Workflow Instance

If the organization is using dynamic workflows, the model is first linked to a workflow template. The template determines which workflow definition should be used.

Model
↓
Workflow Template
↓
Workflow Definition
↓
Workflow Instance

Once the workflow starts, SAS MRM creates a workflow instance.

The workflow definition serves as the blueprint, but the workflow instance represents the actual execution of that process. It tracks tasks, approvals, status changes, notifications, and workflow history for that specific object.

For example, an organization might maintain multiple workflow definitions for different governance scenarios:

Standard Model Workflow
AI Model Workflow
High-Risk Model Workflow

Although these workflows may be very different, they all follow the same architectural pattern:

A business object is created.
The object is associated with a workflow definition, either directly or through a workflow template.
A workflow instance is created when the workflow starts.
Users complete tasks and approvals.
The object progresses through its governance lifecycle.

At this point, you should be able to understand how the major workflow components interact:

Business Objects are the items being governed.
Workflow Definitions describe the process.
Workflow Templates provide flexibility by connecting objects to workflow definitions.
Workflow Instances represent the running execution of a workflow.

Understanding these relationships is the foundation for every advanced workflow administration task. Whether you're configuring dynamic workflows, managing workflow versions, migrating active workflow instances, or troubleshooting workflow issues, everything begins with a solid understanding of how these components work together.

Find more articles from SAS Global Enablement and Learning here.