Process Lifecycle
Overview
Building a business process isn't a one-time event—it's an ongoing journey of design, deployment, and refinement. FlowOn BPM implements a controlled Lifecycle that ensures changes are managed safely, existing work isn't disrupted, and you always have a clear audit trail.
The Three Lifecycle States
Every FlowOn BPM process exists in one of three states:
| State | Purpose | Editable | Executable |
|---|---|---|---|
| Draft | Design workspace for creating and modifying processes | ✅ Yes | ❌ No |
| Published | Immutable, versioned snapshot ready for activation | ❌ No | ❌ No (until activated) |
| Active | Live production version receiving new instances | ❌ No | ✅ Yes |
Draft State
The Draft state is your design workspace—a safe sandbox where you can freely create, modify, experiment, and iterate on your process definition without any impact on production.
| Aspect | Details |
|---|---|
| Purpose | Design, modify, and refine the process definition |
| Editability | Fully editable—add, remove, reorder, or reconfigure any component |
| Executability | Not executable; cannot receive process instances |
| Visibility | Visible only to process designers and administrators |
What you can do in Draft state:
- ✅ Add, remove, or reorder stages
- ✅ Configure stage properties, assignments, and permissions
- ✅ Define transitions and branching logic
- ✅ Set up automation triggers (on enter, on exit events)
- ✅ Configure notifications and escalations
- ✅ Validate the design for completeness
A draft is never executable. You can make unlimited changes with zero risk to running processes or business operations.
Publishing Options
Once you've completed designing your process—defining stages, configuring assignments, and setting up transitions—you have two options to move forward:
| Action | Creates Read-Only Version | Immediately Active | Receives Instances |
|---|---|---|---|
| Publish | ✅ Yes | ❌ No | ❌ No (until activated) |
| Publish & Activate | ✅ Yes | ✅ Yes | ✅ Yes |
When to Use Each Option
Use "Publish" when:
- Stakeholder approval is required before activation
- You want to test in a staging environment first
- You're preparing multiple processes for coordinated release
Use "Publish & Activate" when:
- You've already tested and validated the process
- Quick deployment is needed
- It's a minor update to an existing process
Published State
When a draft is published, it becomes an immutable, versioned snapshot—a permanent record that cannot be altered.
| Aspect | Details |
|---|---|
| Purpose | Create an immutable, versioned snapshot ready for activation |
| Editability | Not editable—the published version is permanently frozen |
| Executability | Not yet executable; awaiting activation |
| Versioning | Each publish creates a new version number (1.0, 2.0, 3.0, etc.) |
What publishing accomplishes:
- 🔒 Freezes the design as a specific, immutable version
- 📋 Enables review before going live
- 📚 Maintains history of all process versions
- ⏪ Enables rollback by activating any previous version
Active State
An Active version is your live, production process definition. This is the version that receives new process instances when the process is triggered.
| Aspect | Details |
|---|---|
| Purpose | Execute the process in production |
| Editability | Not editable—active versions are locked |
| Executability | Fully executable; receives new process instances |
| Constraint | Only one version can be active per process at any time |
What happens when you activate a version:
- ▶️ New instances are created using this version's definition
- ⏸️ Previous active version stops receiving new instances
- ✅ Existing instances on any version continue on their original version until completion
When a new version is activated:
- Existing instances continue executing on their original version—no disruption, no migration required
- New instances are created on the newly activated version
- Both versions may have running instances simultaneously during the transition period
This guarantees business continuity and eliminates the risk of breaking in-flight work.
Version Management
| Scenario | System Behavior |
|---|---|
| Activating a new version | Previous active version stops receiving new instances; existing instances continue unaffected |
| Deactivating a version | Version stops receiving new instances; existing instances continue to completion |
| Multiple published versions | Any number can exist; only one can be active; others available for reference or activation |
| Emergency rollback | Activate any previous published version immediately |
Complete Lifecycle Example
| Phase | Actions |
|---|---|
| 1. Create & Design | Create process → Draft generated → Add stages, transitions, automation → Configure assignments |
| 2. Publish | Design complete → Choose Publish or Publish & Activate → Version created (read-only) |
| 3. Activate | Version activated → Process goes live → New instances created |
| 4. Iterate | Business needs change → Create new draft → Modify → Publish as new version → Activate |
Creating a New Draft from Published
When you need to make changes to a published or active process:
- Create New Draft - FlowOn BPM creates a new draft based on the current published version
- Make Changes - Modify the draft as needed
- Publish - Creates a new version number (e.g., v2.0)
- Activate - The new version becomes active; the old version stops receiving new instances
This workflow ensures that:
- You always have a clear history of changes
- You can compare versions
- You can roll back if needed
- Running instances are never disrupted