Simple Process Notation
Most workflow notations were designed for specialists. BPMN defines over 50 element types. UML activity diagrams require formal training. When non-developers need to read or modify a workflow, these notations become a barrier rather than a tool.
Simple Process Notation is Workflow Engine's built-in flowchart notation. It uses three building blocks - activities (states), transitions (edges), and commands (triggers) - to define any state-machine workflow. Anyone who has seen a flowchart can read it. No BPMN training, no UML certification, no special tools.
With Simple Process Notation, business analysts design and review workflows in the same language developers implement them. The diagram a product manager sketches on a whiteboard maps directly to the scheme that WorkflowRuntime executes.
What it is
Simple Process Notation models a workflow as a directed graph. Activities are the states a process instance can occupy, shown as boxes on the canvas. Transitions are the arrows between them, defining which state changes are allowed. Commands are the triggers that move the process across a transition - when a user or system calls ExecuteCommand, the runtime checks for an outgoing transition with a matching command and follows it.
That is the entire model. There are no gateways (branching is multiple outgoing transitions from an activity, each with its own rule). There are no separate event types (timers are configured as transition properties). There are no pools, lanes, or message flows. Every workflow in Workflow Engine - from a two-step approval to a multi-branch order fulfillment pipeline - is expressed with these three elements.
The Visual Designer renders this notation as a flowchart. The Designer saves schemes as XML in Simple Process Notation, which WorkflowRuntime loads and executes at runtime.
For developers: the scheme is stored as XML with a predictable structure. You can read, write, and validate it programmatically without the Designer. The ProcessDefinitionBuilder API in C# produces the same runtime model. See the Scheme concept for the XML format reference.
Why it matters
Simple Process Notation delivers these outcomes:
- Shared language across roles - business analysts, QA engineers, product managers, and developers all read the same diagram. No translation step between "what the business wants" and "what the system does."
- No BPMN toolchain required - you do not need a BPMN modeling tool, a BPMN certification, or a BPMN runtime. The notation is built into Workflow Engine and works with any text editor.
- Portable and diffable - the notation is XML. You can store schemes in version control, compare revisions, generate them from templates, and validate them in CI pipelines.
- Full expressiveness without complexity - conditions, timers, actions, rules, subprocesses, and annotations are all representable within the three-element model. You never outgrow the notation.
Who it is for
Evaluator (CEO, CTO, PM): Simple Process Notation eliminates the notation tax. Your team does not need to invest in BPMN tools or training. Flowcharts are universally understood, and the notation maps directly to executable workflows - no gap between design and implementation.
Developer: the notation is XML with a predictable structure. You can generate, validate, and transform schemes programmatically. The ProcessDefinitionBuilder API lets you build schemes in C# with compile-time checking. Compare revisions in pull requests.
Enterprise architect: the notation is stored as XML files that you can keep in version control, diff in code review, and validate in CI pipelines. The format is independent of any single modeling tool - you can edit schemes in the Visual Designer, in any text editor, or generate them programmatically.
When to use it
Use Simple Process Notation when you want a workflow definition that is easy to read, store in version control, and share across teams. It fits any process that maps to a state machine - and most business processes do. Typical signals that the notation is a good fit:
- Non-developers need to read or review the workflow - product managers, compliance officers, or business analysts who understand the process but do not write code. The three-element model is readable without training.
- You want to version control workflow definitions - schemes are XML files. Store them in git, diff them in pull requests, tag releases alongside your application code.
- BPMN is overkill for your use case - your processes are internal approval flows, document routing, or task sequences. The full BPMN specification adds complexity without benefit. Simple Process Notation covers the same scenarios with fewer concepts.
- You need to generate workflows programmatically - generate scheme XML from an external system, a configuration file, or a template engine. The predictable XML structure means you can produce valid schemes without the Designer.
How it compares
Workflow Engine supports three ways to define a process. Simple Process Notation is the middle ground between visual modeling and writing code.
| Approach | Best for | Tradeoff |
|---|---|---|
| Simple Process Notation (flowchart XML) | Business analysts and developers who need a readable, portable format that maps directly to execution. | Requires understanding the three-element model. Less expressive than BPMN for cross-system choreography. |
| BPMN 2.0 (import/export via plugin) | Teams that already use BPMN tools and need to exchange diagrams with external partners. | Over 50 element types, requires training. Import fidelity is not lossless. |
Programmatic (C# ProcessDefinitionBuilder) | Developers who want compile-time safety, version control, and the full power of the language. | Not readable by non-developers. Requires code deployment for every change. |
All three approaches produce a scheme that WorkflowRuntime can execute. You can choose the approach that fits your team and workflow - use the Visual Designer during prototyping, write XML for version-controlled definitions, or use ProcessDefinitionBuilder for compile-time safety.
Frequently asked questions
How does Simple Process Notation differ from BPMN?
BPMN defines over 50 element types including gateways, events, pools, lanes, and message flows. Simple Process Notation has three elements: activities, transitions, and commands. Branching uses multiple outgoing transitions guarded by rules instead of explicit gateway nodes. Timers and callbacks are transition properties, not separate event types.
Can I import existing BPMN diagrams?
Yes. Workflow Engine supports BPMN 2.0 import and export. The importer maps BPMN tasks to activities, sequence flows to transitions, and start events to initial activities. Complex constructs such as boundary events or multi-instance loops may need manual adjustment after import.
Who can read a scheme written in Simple Process Notation?
Anyone who has seen a flowchart. Activities are boxes, transitions are arrows, and the command name on each arrow tells you what trigger moves the process to the next state. No BPMN training, no UML certification, no special tools required.
Do I need the Visual Designer to create a scheme, or can I write it directly?
Both. The Visual Designer renders and saves schemes in Simple Process Notation. You can also write the XML directly in any text editor or generate it programmatically. The XML format is stable and well-understood by the runtime parser.
Is Simple Process Notation the only notation Workflow Engine supports?
No. Workflow Engine also supports BPMN 2.0 import and export and the programmatic ProcessDefinitionBuilder API. Simple Process Notation is the default notation used by the Designer and stored in the persistence layer. You can mix approaches in the same project.