Executable vs. Non-Executable Process Models

Estimated reading: 7 minutes 8 views

When you’re modeling a business process, the question isn’t just “what happens next?” — it’s “who will act on this, and how?”

That’s where the distinction between executable and non-executable BPMN models becomes critical.

One model can guide conversation. Another can run software. Confusing them leads to wasted time, misaligned teams, and failed automation efforts.

After two decades of working with organizations from startups to global enterprises, I’ve seen this confusion repeat — not because people don’t understand BPMN, but because they don’t know how to *use* it for its intended purpose.

This chapter cuts through the noise. You’ll learn how to choose between a descriptive BPMN process for documentation and an executable BPMN process model for automation — and how to transition from one to the other with confidence.

By the end, you’ll know which elements matter for execution, which are safe to leave out, and how to avoid the trap of over-engineering a model that’s meant to be a conversation starter.

Understanding the Core Difference

At its heart, the difference between executable and non-executable BPMN models comes down to intent.

A descriptive BPMN process exists to communicate. It shows what a process *is*, not how it *runs*.

An executable BPMN process model, by contrast, is a machine-readable specification. It defines the exact behavior a process engine must follow.

Think of it like this: a descriptive model is a blueprint for a building. An executable model is the set of instructions a construction robot follows — precise, unambiguous, and ready to execute.

They’re both valuable. But using the wrong one in the wrong context creates friction.

When You Need a Descriptive BPMN Process

Use a descriptive BPMN process when your goal is clarity, alignment, or documentation.

Examples include:

Onboarding new team members to a business process
Presenting a high-level workflow to stakeholders
Mapping a process for compliance or audit purposes
Facilitating a workshop to identify pain points

These models don’t need to be executable. In fact, forcing execution-ready syntax into them often adds noise.

For instance, I once worked with a finance team that had a 12-step approval process. They modeled it in BPMN with every gate, every condition, and every data object — all for a presentation to executives. The result? A dense diagram that obscured the real issue: too many approvals.

They didn’t need an executable model. They needed a simple, visual story.

When You Need an Executable BPMN Process Model

Use an executable BPMN process model when you’re preparing to deploy a process to a workflow engine — such as Camunda, Activiti, or Microsoft Power Automate.

Here, every element must be precise, unambiguous, and technically valid.

Key constructs that matter for execution:

Service tasks with defined operation references
Data objects and data associations that map to variables
Message events with correct correlation keys
Timer events with valid expressions (e.g., ISO 8601)
Boundary events with correct error codes or cancellation behavior
Sequence flows that are not just logical, but executable

These aren’t optional. They’re required for the engine to interpret and run the process.

For example, a “Send Email” task must reference a specific email service — not just say “send an email.” Otherwise, the engine doesn’t know what to do.

What’s in a Model? A Practical Breakdown

Let’s compare a descriptive BPMN process and an executable one side by side — using a real-world example: a customer onboarding workflow.

Descriptive BPMN Process (Documentation-First)

This version focuses on clarity and stakeholder understanding. It shows the flow, responsibilities, and key decisions — but not execution details.

Example elements:

Start event: “Customer submits application”
Task: “Verify identity” (no service reference)
Exclusive gateway: “Is identity valid?”
Task: “Send welcome email” (textual description only)
End event: “Onboarding complete”

It’s clean. It’s readable. It answers: “What happens in this process?”

But it’s not ready to run.

Executable BPMN Process Model (Automation-Ready)

This version includes all the technical details needed for execution.

Same process, but now:

Task: “Verify identity” → serviceTask with camunda:operation="verifyIdentity"
Gateway: “Is identity valid?” → conditionExpression with ${identityVerified == true}
Task: “Send welcome email” → serviceTask with camunda:operation="sendWelcomeEmail" and dataInput mapping to customer.email
Timer event: “Follow-up reminder” → timeDuration="P7D"

Now the process engine knows exactly what to do, when, and with what data.

It’s not just a diagram. It’s a program.

How to Evolve from Descriptive to Executable

Many teams start with a descriptive model — and that’s perfectly valid. But the real power comes when you evolve it into an executable one.

Here’s a practical path:

Start with a descriptive model to align stakeholders and capture the process logic.
Validate the flow with business users — make sure no steps are missing, and decisions are clear.
Identify automation candidates — which tasks can be automated? Which decisions are rule-based?
Map data — define what data is needed at each step, and how it flows.
Add executable constructs — service tasks, data mappings, expressions, events.
Validate with a process engine — test the model in a simulation or deployment environment.

It’s not a one-way transformation. You’ll often go back and refine the descriptive model based on execution feedback.

For example, during a simulation, you might discover that a “manual review” step is causing bottlenecks. You can then rework the descriptive model to reflect a new, automated review path — and update the executable model accordingly.

Key Trade-Offs to Consider

Not every process should be executable. Here’s when to pause and ask: “Do I really need this?”

Use Case	Recommended Approach
Process documentation for training	Descriptive BPMN process
Internal audit or compliance review	Descriptive BPMN process
Deploying a workflow to a digital platform	Executable BPMN process model
Integrating with an external system (e.g., CRM, ERP)	Executable BPMN process model
Facilitating a cross-functional workshop	Descriptive BPMN process

Remember: a descriptive model is a conversation tool. An executable model is a contract with a machine.

Tools and Best Practices

Modern BPMN tools — like Visual Paradigm— support both modeling styles. But they don’t always make the distinction clear.

Here’s how to stay sharp:

Use different diagram types for different purposes. A process diagram for internal flow, a collaboration diagram for partner interactions.
Tag models with labels like “Draft – Descriptive” or “Final – Executable” to avoid confusion.
Use a consistent naming convention for tasks, data, and events — especially when transitioning between models.
Validate with simulation early and often. Don’t wait until deployment to find issues.
Document assumptions — especially when omitting execution details in a descriptive model.

One team I worked with used a simple color code: green for executable elements, yellow for descriptive ones. It took 10 minutes to set up — but saved hours of debate.

Don’t over-model. Don’t under-model. Model with purpose.

Frequently Asked Questions

Can a single BPMN diagram be both descriptive and executable?

Technically, yes — but it’s not recommended. A model that tries to serve both purposes often becomes bloated and confusing. It’s better to use separate diagrams: one for discussion, one for execution.

What happens if I try to deploy a descriptive BPMN process to a process engine?

The engine will likely reject it. Missing service task references, invalid expressions, or undefined data objects will cause parsing errors. Always validate the model before deployment.

Do I need to model every step as executable?

No. Only the steps that need to be automated. Manual tasks, approvals, or human interventions can remain non-executable — as long as they’re clearly marked and understood.

How do I know if a process is ready to become executable?

Ask: “Can a machine follow this process without ambiguity?” If the answer is “not really,” then you’re not ready. Add data mappings, conditions, and service references until it’s unambiguous.

What’s the biggest mistake teams make with executable BPMN models?

Over-specifying. They add technical details too early — before the process logic is agreed upon. This leads to rework, frustration, and models that don’t reflect reality.

Is it possible to automate a process that started as a descriptive model?

Absolutely. That’s one of the main benefits of starting with a descriptive model. It gives you a shared understanding. Then, layer in execution details incrementally — based on business need, not technical whim.