Workflow Wendy
“If something waits, retries, or has arrows, it needs BPMN and a committee trained to move diamonds.”
Isn’t this another workflow engine with a more expensive hoodie?
Elevator answer
If the product is a three-week claims process with human work queues and BPMN, use a workflow engine. TPF starts with typed Java execution and adds a durable Await where the real flow must stop.
3 coffee-machine misconceptions
Kafka Frank
“A topic is already a workflow engine, provided nobody asks where the state went.”
Microservice Mike
“Split every step into a deployment and the architecture will coordinate itself through optimism.”
The real explanation
Workflow engines solve a real problem. A claim arrives on Monday, waits for an adjuster, escalates on Friday, and resumes after somebody uploads a police report next month. If queues, calendars, visual process management, and human tasks are the product, choose the tool built for them. A pipeline is not improved by pretending to be cheaper BPMN.
TPF starts with Java work such as validate order, observe risk, decide, and charge. It checks how the step types connect, which mapper is selected, where the connector sits, and which adapter must be generated. An Await can make one pause durable; the framework is still not a visual language for drawing the organisation chart in arrows.
The difference matters before anything goes wrong. In a workflow engine, the durable process model is usually the dominant unit. Activities are coordinated because the engine owns the process life cycle. In TPF, the dominant unit is the typed flow and the operational semantics surrounding it. A domain function still says something concrete—validate a request, calculate a price, enrich an order, decide a result. TPF’s shell then provides the necessary admission, transport, retries, telemetry, persistence, replay, and generated adapter behavior around that function.
TPF can include await boundaries, retries, and checkpoint handoffs. Those features are not proof that it has secretly become Camunda without a diagram editor. A reliable application must occasionally wait for an external fact, survive a crash, reject duplicate completion, resume with correlation, or hand work to another pipeline. TPF treats those as execution semantics that must remain durable and replay-safe across adapters. It does not conclude that every business path should be modeled as a general-purpose process definition.
There is a useful test: who needs to change the model most often? If business stakeholders need to design, inspect, and alter a visible long-lived process independently of application releases, a workflow engine optimizes for that conversation. If developers need to keep typed domain behavior coherent while the same flow acquires REST, gRPC, LOCAL execution, generated transports, retries, or an await boundary, TPF optimizes for that conversation. Neither answer is morally superior; they make different things cheap.
TPF is also intentionally less interested in pretending that arrows solve distributed systems. A diagram can show a retry, but it does not prove idempotency. It can show a wait, but it does not guarantee durable correlation, timeout behavior, duplicate completion handling, or replay-safe lineage. TPF wants those constraints to be part of the compiler and runtime contract. That is a less cinematic ambition than a process canvas, and often a more useful one for application code.
The trade-off is that TPF does not give a business analyst a universal workflow workbench. Its flow descriptions are for application semantics, not a replacement for every business-process management practice. It also refuses the comforting fiction that a pipeline is a tiny distributed orchestration platform waiting to be promoted. If the durable process itself is the product, choose the tool that owns it wholeheartedly.
The memorable distinction is this: a workflow engine asks how a process should persist and advance; TPF asks how typed business execution should remain honest when it encounters the outside world. Those questions overlap at awaits and retries, but they do not collapse into one another.
That separation lets a team use a workflow product where people and long-lived process state are the centre of the system, while using TPF where the difficult work is keeping application behavior typed, observable, and consistent across execution boundaries. A healthy architecture does not need one product to win every category.
Trade-offs
TPF gains typed contracts and generated application boundaries without requiring every flow to become a durable business process. It gives up a universal visual process language and the rich human-task tooling many workflow products provide. A team must decide explicitly which boundaries truly need durable coordination.
When TPF is not a good fit
Choose a workflow engine when the business process is long-lived, human-operated, visually managed, and expected to evolve independently of the application’s typed code. TPF is also not the right answer for a team seeking a generic orchestration product for arbitrary tasks rather than a framework for application flows.