Process Lifecycle

Overview

Building a business process isn't a one-time event - it's an ongoing journey of design, deployment, and refinement. Logic Process Orchestrator 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 Logic Process Orchestrator 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

Key Principle

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 assigns the next sequential version number (1, 2, 3, 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
• ♻️ Spins up a fresh draft - a new Draft version is automatically created from the just-published snapshot, so the next round of edits can begin immediately

Version Numbering

While in design, a version carries the literal label Draft. Publishing replaces that label with the next whole number in sequence (1, 2, 3, …) - there are no minor/decimal version numbers. Only the Draft version is editable; published versions are frozen and cannot even be deleted.

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

Instance Continuity Guarantee

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:

1. Create New Draft - Logic Process Orchestrator creates a new draft based on the current active (or last published) version. If a draft already exists, editing reopens it rather than creating another
2. Make Changes - Modify the draft as needed
3. Publish - Assigns the next sequential version number (e.g., v2)
4. Activate - The new version becomes active; the old version stops receiving new instances. Activation requires a published version - a draft cannot be activated directly

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