The Problem Space

Imagine implementing a typical Leave Request Workflow:

1. Employee submits a request (notify the direct manager).
2. Direct Manager approves or rejects (if rejected, notify the employee).
3. If approved and the leave duration exceeds 15 days, the Section Head must approve (send notification).
4. Regardless of previous outcomes, the request is sent to the HR department.
5. If approved by HR, the request is processed; if rejected, the employee is notified.
6. Audit logs are written at each step.

While this logic can be implemented using plain C#, as complexity increases—due to branching, retries, compensation, async calls—it becomes difficult to manage, maintain, and test. This is where workflow engines prove their value.

A workflow engine provides a structured, reusable way to model, execute, and manage business processes. Instead of hardcoding logic into services or controllers, workflow engines allow you to:

• 📋 Define states (e.g., Submitted, Approved, Rejected)
• 🔁 Configure transitions between states through actions or rules
• 👤 Handle human-driven steps, such as approvals or reviews
• 💾 Persist long-running workflows and resume execution later
• 🔍 Record audit logs for traceability and compliance

Workflow engines are ideal for scenarios like business approvals, employee onboarding, document lifecycles, and other multi-step decision-based processes.

Some engines are designed as general-purpose orchestrators. Others, like Meridian Workflow, are purpose-built for stateful, user-interactive workflows with strongly-typed fluent definitions.

You can either build your own workflow engine or use an existing open-source solution tailored to your needs.

---

Existing Workflow Engines at a Glance (Open Source)

A quick survey of popular open-source workflow engines yields several solid candidates:

• Workflow Core -in github
• Elsa Workflows - in github
• Meridian Workflow - in github

Let’s explore the strengths and trade-offs of each, to help choose the right one.

Workflow Core

• ✅ Lightweight and C#-first.
• ❌ JSON-serialized persistence, lacking type safety during deserialization.
• ❌ No fluent API; workflows are defined by implementing interfaces.
• ❌ Refactoring is error-prone — issues appear at runtime rather than compile-time.

Elsa Workflows

• ✅ Rich feature set, visual designer, multiple persistence providers.
• ❌ Heavyweight — significant dependencies and steep learning curve.
• ❌ Workflow definitions use verbose JSON or C# models.
• ❌ Often overkill for simple state-based business logic.

Meridian Workflow

Meridian Workflow is designed specifically to fill the gap between simplicity and power:

• 💎 Pure C# DSL — workflows are defined entirely in C#, without JSON or visual designers.
• ✅ Compile-time safety — all input and output types are enforced by the compiler.
• ⚙️ Fluent API — simple chaining with .State(...), .Action(...), .When(...), .AddHook(...), etc.
• ⚡ Minimal overhead — no required UI, database, or service bus.
• 🛠 Easy testing — workflows can be executed in-memory and fully unit tested.

Feature Comparison Table

---

Conclusion

It’s clear that for state-machine, human-centric, or approval-based workflows, Meridian Workflow is the ideal choice.

It offers:

• Clear, strongly-typed definitions
• Built-in support for approvals and roles
• Easy testing and minimal overhead
• A developer-first experience

---

🚀 Bookmark-worthy?

If you ever revisit a workflow engine deep dive, this post might be one of those. Having it saved for when you're building approval flows could come in handy.

💬 Your turn

What’s been your toughest workflow challenge? Seeing your own use cases reflected here would help inform Part 2—and maybe spark ideas for others in the comments.

---

🔜 Coming soon: Part 2

We’ll be diving into setting up a Leave Request flow in Meridian Workflow—covering state definitions, approval actions, and transitions, step by step.

See you there!