Temporal is a powerful platform for building reliable, long-running workflows.

But the real trigger for Zigflow wasn't frustration with the SDK.

It was conversations.

In the space of a week, I spoke to three different customers who all said the same thing:

We love Temporal, but we want to allow our non-technical users to define workflows.

In practice, there are usually two answers in that situation:

1. use the SDK
2. build your own DSL

I thought the Temporal community should provide a third option. Here's one approach.

Zigflow is a declarative layer on top of Temporal.

It simplifies workflow orchestration by treating workflows as configuration rather than code.

Understanding when not to use Zigflow is just as important as understanding when you should.

Zigflow allows workflows to be defined declaratively in YAML.

Under the hood, everything still runs on Temporal.

So how does that mapping actually work?

One of the more common questions about Zigflow is:

Why not convert the YAML into Go code and compile it into a Temporal workflow?

At first glance, that seems like a natural approach.

You keep full access to the Temporal SDK, while still allowing workflows to be defined declaratively.

But Zigflow deliberately does not do this.