How to route documents down different paths – review, approval, publish, hold – from a single Confluence workflow, without approval-gate workarounds or cloned copies.

Every team that runs documents through Confluence eventually hits the same wall. The process in your head has forks in it – this document needs a full review, that one just needs a quick sign-off; this page goes to QA, that one publishes straight away – but the workflow you built only goes in a straight line. So you improvise. You bolt on an extra approval gate to fake a decision point. You clone the whole workflow so a handful of pages can take a different route. You keep a spreadsheet, or you just do the routing by hand and hope everyone remembers the rule.

None of that is a workflow. It’s a workaround. And workarounds are fragile: they live in one person’s memory, they break when that person is away, and they quietly stop matching how the team actually works.

A branching workflow is one where a single status can lead to more than one next step, and the person working the document chooses which path to take. Instead of a fixed, linear sequence – draft, review, approve, publish, in that order every time – a branching (or non-linear) workflow lets one stage offer several outgoing transitions, so you get multi-path approval from a single template.

That’s exactly what Workflows for Confluence branching does. A stage can now present multiple named paths, and the person working the document picks the right one – right from the byline. It’s a small change to the mechanics and a big change to what a workflow can honestly represent. For the first time, the workflow you build can mirror your real internal process, forks and all, instead of approximating it.

Branching isn’t automation that makes decisions for you, and it isn’t about squeezing more speed out of a process. It’s about something more useful: making the paths your documents already take official.

The decision that used to live in a person’s head – “this one skips SME review because it’s a minor edit” – becomes a named branch in a workflow that everyone can see and follow. The routing that used to depend on someone remembering the rule now happens right where the work does, in the byline, with a single click. That’s the shift worth caring about: from improvised routing that only the workflow owner understands, to standardized paths the whole team can run with confidence.

Three things follow from that, and they’re the reason branching matters more than it first appears:

It’s standardized. One workflow, with its forks built in, becomes the single source of truth. You retire the cloned copies and the shadow processes. When someone new joins, the paths are in front of them, not in a colleague’s inbox.

It’s scalable. Because the branching lives inside the workflow template, you build it once and bulk-apply it across an entire space or instance. You’re not maintaining five near-identical workflows for five variations of the same process – you’re maintaining one that knows how to branch.

It’s bespoke. This is the part teams feel most. The workflow finally reflects your process – your review stages, your hold reasons, your publishing rules – rather than bending your process to fit a tool’s straight line. And because the choice happens in the byline, at the moment of work, the routing is a natural part of using the page, not a separate administrative act.

Sophisticated, flexible, tailored – but the plain-English version is simpler: your workflow can finally look like your process.

The clearest way to understand branching is to see the shapes real teams build with it. Here are four patterns we keep seeing, drawn from how teams across regulated content, life sciences, manufacturing and product documentation are already using it.

A compliance-minded documentation team drafts content that sometimes needs a full subject-matter-expert review and sometimes just needs a light technical check. Before branching, that meant two workflows – or a manual decision nobody could audit. 

Now a single Draft stage branches on request type: a full change goes to SME review first, a simple change skips straight to the editorial and technical audit. After the audit, a second branch handles the outcome – publish now, place on hold by reason, or send back for re-review. 

One template, several official routes, and every decision recorded in the page’s history.

Here’s how to do it:

A team evaluating a move away from Comala Document Management wanted to keep a workflow where a document at draft could head down whichever path suited it – review, approval, QA, or straight to publish, with the author choosing. In a linear tool that’s impossible without cloning. With branching, Draft becomes a hub that fans out to every path, and most stages can loop back to draft for changes. It’s a natural migration target: the multi-transition behaviour Comala users rely on, rebuilt as a workflow the team owns and can bulk-apply themselves.

Follow this guide:

A product documentation team uses Confluence as a staging area before content syncs out to their knowledge base. Pages move through draft, technical review and final review, with visibility widening at each stage. At the publishing gate, branching lets the writer choose which permission path a page takes – locked down, or open to a specific group. And because you can restrict who fires a given transition, the team lead keeps a manager-only “send it back” path from the published state, without blocking anyone else’s normal flow.

Four teams, four very different processes – and one feature quietly making each of them official.

These are the steps:

We’ve turned each of these into a ready-to-use template, so you don’t have to design the pattern from scratch. Each one is built in the no-code workflow editor: You drag your stages onto the canvas, drop in a branching step wherever a stage needs to offer a choice, name each branch and save. Bulk-apply it across your space, and the process your team has been running by memory becomes something they can follow by design.

If you take one thing from this: the next time you find yourself adding an approval gate you don’t really want, or cloning a workflow to handle one exception, stop. That’s your process telling you it has a fork in it. Now you can build the fork.