Software For Workflow Management

Workflow management software tracks work as it moves between people: who has it now, what state it is in, what has to happen before it moves on. That is a different job from workflow automation, which runs steps without a person, and the two get sold together often enough that teams buy an automation platform to solve a visibility problem.

We sell source code you clone and run yourself, so there is no hosted workflow product here. For most teams the right answer is a tool that already exists, and quite often one they are already paying for.

You may already own one

The free and Microsoft-shaped variants of this search are the most common ones, which suggests a lot of people are looking for something they have already bought.

When the existing tool is not being used, the reason is usually not a missing feature. It is that the work arrives somewhere else, normally email or a chat message, and the tool requires someone to re-enter it. Anything that does not fix the intake will be abandoned the same way.

What makes a workflow tool fit

Assuming a new tool is genuinely needed, four things separate the ones that survive from the ones that get quietly abandoned.

Automation is a separate decision

Once the states exist and work is flowing, some of the transitions can happen without a person. That is worth doing and worth doing after, not instead.

The reason for the ordering is that automating a process you have not observed tends to encode the version people describe rather than the version they run. Recording states for a few weeks first usually reveals a step everybody skips and a loop nobody mentioned, and automating the described version of the process makes both worse.

There is also a cost that is easy to miss. Automation platforms usually meter runs or tasks, and a workflow that fires on every record change can consume a plan quickly. Check what the meter counts before wiring anything to a high-volume trigger.

When teams end up building

Two shapes, and only one of them is common.

The rare one is an internal process so specific that no tool models it. This is less common than it feels, and the usual outcome is that the process is unnecessarily complicated rather than genuinely unusual.

The frequent one is a workflow that faces customers. An agency where clients approve deliverables, a lender where applicants upload documents and see progress, a service business where the customer is a participant in the process rather than a spectator. Internal workflow tools handle external participants poorly, and giving a customer a seat in your internal tool is usually the wrong answer on both security and experience grounds.

What you would start from here

There is no workflow engine in this stack, no state machine, no approval model, no task inbox and no automation builder. What exists is the application those things would live inside.

The Vault template gives you organizations as the boundary work belongs to, roles and invitations, a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing for the customer-facing case. For the process itself, a status column with an enum, a table recording transitions, and a job runner covers a surprising amount of ground, and it ships with your code rather than becoming a service to operate.

If the process must survive restarts, retry for days, and never duplicate a side effect, that is where a durable execution engine earns its cost. Temporal is the usual choice and it is theirs rather than ours, running alongside this rather than arriving with it.

You would write the states, the transition rules, who may make each transition, and the intake path that turns an email or a form into a record. The packs and screens below are the accounts, tenancy and admin layer underneath that.