Why BPMN looked good but did not work for us

Every workflow tool faces the same architectural question early on. Do you build a flowchart editor? Or do you build something simpler?

BPMN - Business Process Model and Notation - is the industry standard. Gateways, events, pools, swimlanes. It looks professional. Enterprise buyers expect it. Consultants are trained in it.

We chose not to build it. This post explains why.

April 2017: The visualization debate begins

I was obsessed with how people think about processes. Back in April 2017, I wrote this to our design team:

“Customers are thinking about processes visually… we need to come up with a view in builder that lets someone visualize the entire process flow - without actually doing flowcharts.”

That last phrase was the key constraint. Visualize without flowcharts. Show the flow without boxes and arrows everywhere.

The sketch shows what we were thinking. Steps flow vertically. Diamonds mark approvals. Dotted lines show conditional boundaries. Question marks indicate steps that might not appear.

But I added a critical constraint in the same discussion:

“Note that the steps are always shown linearly/vertically - we never scroll or lay them out horizontally - making it okay for phones. We never want to actually get into full-on flowcharts.”

That decision shaped everything that followed.

The mobile problem nobody talks about

Here is the thing about BPMN diagrams. They sprawl. A typical process with fifteen steps and three decision points becomes a diagram that requires horizontal scrolling, zooming, and panning to understand.

Try viewing that on a phone. It does not work.

From a GitHub issue we logged in 2019:

“Mobile and tablet ready - whereas big flowcharts are impossible to view on phones”

This was not just a nice-to-have concern. We were building workflow software for people who work in the field, in warehouses, on job sites. They do not have 27-inch monitors. They have phones.

A vertical list of steps? That scrolls perfectly on any device. A sprawling BPMN diagram? Useless on mobile.

What swimlanes actually show

Pravina Pindoria, our product designer, pushed back on my original sketches. She pointed out what I was missing:

“The above view shows just 1 element: What needs to be done. It is missing: Who needs to do it, When it needs to be done.”

She was right. Traditional swimlane diagrams encode three dimensions:

• What happens (the steps)
• Who does it (the swimlane columns)
• When it is due (the timeline)

My linear sketches only captured the first one.

See the difference? Same steps as my original sketch. But now you can see who does each one (the avatar circles) and when (the “1 day” and “1 week” markers).

Pravina added:

“We will need to incorporate all 3 elements into a mobile-friendly view.”

The challenge was encoding swimlane-level information in a vertical, scrollable format. That is harder than it sounds.

The vocabulary problem

One thing became clear from customer feedback. BPMN terminology confused people.

From GitHub issue #15983:

“Users do not understand terms like ‘Visibility action’. Users naturally think ‘Hide or show a step’”

This was a recurring pattern. We would use technical language that made sense to process professionals, and normal users would be lost.

BPMN is full of this. Gateways. Events. Message flows. Pools. Lanes. Artifacts. Each term has a precise meaning in the specification. But when you put a process owner in front of a BPMN editor, they freeze.

They know what they want. “If the order is over ten thousand dollars, get manager approval.” They do not know how to express that in BPMN notation.

We decided early on: plain English wins. “If this, then that” beats “exclusive gateway with conditional sequence flow.”

The Flowtable concept

In October 2019, I opened GitHub issue #15160 with an idea we called Flowtables:

“Flowtables will provide what flowcharts cannot: Intuitive color coding, More than just sequence, No hierarchies or messy lines, Easy to understand for people who do not understand flowcharts”

The concept was a grid. Rows for steps. Columns for different dimensions - who, when, what type. Color coding for status or category.

“Mobile and tablet ready - whereas big flowcharts are impossible to view on phones”

Tables compress information. A flowchart spreads twenty steps across a huge canvas. A table shows the same twenty steps in a compact grid that fits on a screen.

Think about spreadsheets. People understand spreadsheets. They do not understand BPMN.

The Flowtable never shipped as originally conceived. But the philosophy - data density over visual sprawl - influenced how we built the tracker view.

The bridge we were trying to build

I kept coming back to this phrase in our internal discussions:

“Crosses the bridge between full-blown flowchart and primitive checklist”

That was the positioning problem. On one end, you have enterprise BPM tools with full BPMN support, modeling environments, execution engines. Powerful but complex.

On the other end, you have simple checklist apps. Easy to use but no conditional logic, no branching, no automation.

We wanted something in between. Complex enough to handle real business processes. Simple enough that anyone could build one without training.

From a related design discussion:

“We want something ‘in between’ flowcharts and checklists to see a summary of all dependencies.”

That middle ground is what we spent years trying to find.

Why if-this-then-that won

The answer we landed on was rules. Not visual programming. Not drag-and-drop flowcharts. Text-based rules.

“IF (trigger object) | Is (trigger) | THEN (action) | THAT (action object)”

That four-part structure came from Pravina in September 2017. It became the grammar of everything we built for automation.

The advantages over BPMN were practical:

Readability. “If department equals International, show the customs step” reads like English. A BPMN diagram showing the same logic requires understanding gateway notation.

Composability. Rules can stack. Add another condition. Chain actions together. You do not need to redraw a diagram.

Testability. Enter a test value, see what the rule does. Try different inputs. Iterate fast. BPMN diagrams are static until you deploy them.

Mobile-friendliness. A list of rules fits on a phone screen. A complex gateway diagram does not.

The if-this-then-that tutorial shows where this ended up. The philosophy - text rules over visual diagrams - survived intact.

What we left out on purpose

We made deliberate choices to not build certain things:

Full BPMN notation support. No gateways, events, pools, message flows. The notation is powerful but the learning curve kills adoption.

Visual flowchart editor. No drag-and-drop canvas. No connector lines to arrange. Those editors feel productive but create maintenance nightmares.

Swimlane visualization. We capture who does what (assignments) and when (deadlines) but we do not render them as horizontal swimlanes. The data is there; the visualization is different.

Process simulation. Some BPM tools let you simulate processes before deployment. We went with “test the rule” instead of “simulate the whole workflow.” Faster iteration, narrower scope.

From an internal architecture discussion:

“We only show step title and icons against the steps to represent types e.g. approval steps would be diamond icons to keep this familiar with BPMN/UML.”

We kept the diamond icon for approvals. That is about as much BPMN visual language as we preserved.

The enterprise feedback that validated the approach

Real customer feedback confirmed we were on the right track. From a large enterprise real estate company:

“Currently the process steps are being displayed linearly, but processes can be dynamic and non-linear. This linear workflow interface makes it difficult for users to build steps.”

They wanted more flexibility. But notably, they did not ask for a BPMN editor. They wanted better ways to express conditional logic within our linear structure.

That distinction mattered. The problem was not “we need flowcharts.” The problem was “we need better conditionals in the existing format.”

We solved that with richer rule types, not with a diagram editor.

The vision that guided us

I wrote this in October 2017, and it still captures what we were trying to do:

“Our mission is to make that flowchart look ‘out of date’. Also - we are collecting sticky info like comments in our system, rendering the original flowchart a boring relic.”

Traditional BPMN diagrams are static documentation. They sit in Visio or Lucidchart. They get out of date the moment the process changes.

Our approach? The template is the documentation. When you run a process, the actual execution - who did what, when, with what comments - becomes the source of truth.

A living process beats a stale diagram every time.

The never-ending feature battle

Pravina observed something in February 2018 that stuck with me:

“This will be a never ending feature battle”

She was looking at competitors adding more and more BPMN features. Richer notation. More gateway types. Complex event handling.

We could have joined that race. Built a better BPMN editor. Added more shapes and connectors.

Instead, we went the opposite direction. Fewer concepts, better executed. If-this-then-that instead of forty BPMN element types.

The temptation to add complexity never goes away. Customers ask for features. Competitors ship features. The natural drift is toward complexity.

Our response: resist it. Simple rules. Linear layouts. Mobile-friendly views. Text over diagrams.

Where this ended up

Years later, the core philosophy holds. The automations system uses rules, not diagrams. The template builder is linear, not a canvas. Conditionals are text-based - if this field equals this value, show this step.

People build complex workflows without ever drawing a flowchart. International shipping processes with regional variations. Approval chains with multiple escalation paths. Onboarding workflows that adapt based on employee type.

All without BPMN notation. All viewable on a phone.

The bridge between flowcharts and checklists? Turns out it is not a visual hybrid. It is rules that non-technical people can write and understand.

BPMN looked good on paper. For us, it did not work.