One Document, Many Procedures: Structure Detection

Real SOP documents rarely describe exactly one procedure. A warehouse receiving manual might also contain a damage escalation process, a returns procedure, and a supplier notification routine. If you import that document as a single 40-step workflow, workers have to wade through steps that do not apply, and none of the embedded procedures can be run on its own.

Structure detection is OpsBrain's answer. When you import a document, the AI reads the extracted draft and looks for distinct procedures tucked inside it. If it finds them, you get a review screen before the editor: a proposal to split the upload into a parent routine plus sub-workflows, wired together with decision steps so the whole thing still runs end to end.

You stay in control at every point. The proposal is just a proposal: you can accept the split, or keep everything as a single workflow. Either way, nothing goes live until you publish.

Detection runs automatically after an import finishes extracting a draft. You do not switch anything on. But it deliberately stays out of your way in several cases:

• Small drafts are skipped entirely. If the extracted draft has fewer than 4 steps, there is nothing worth splitting and you go straight to the editor. No review screen appears.
• The AI has to be confident. The review screen only appears when the analysis both recommends a split and identifies at least 2 distinct workflows.
• Tiny fragments are folded back in. A proposed sub-procedure needs at least 2 steps of its own; anything smaller is absorbed back into the parent. If that clean-up leaves fewer than 2 workflows standing, the review screen is skipped and you land in the editor as usual.
• There is a ceiling of 6 workflows per split (the parent plus its sub-workflows). If the document contains more candidate procedures than that, the extras stay inside the parent.

When detection does find structure, the processing page's success button changes from Open draft to Review structure, and the page redirects you to the review screen automatically.

The review screen carries a Structure detection badge and opens with the headline: "We found … reusable procedures tucked inside this SOP." Below it, the AI explains its reasoning. When no specific reasoning is available, the screen explains the general win: splitting lets your team run each sub-procedure on its own, during audits, handovers, or training, while keeping everything connected through branching.

If the workflow you refined is already live, a notice titled This workflow is already live reassures you: accepting creates a new draft, the currently live version keeps running for workers in flight, and nothing changes for them until you publish the new draft yourself.

The three sections

1. 1Here's what we'd build: a clean parent routine, with sub-procedures the team can run on their own when needed. When sub-procedures launch their own sub-procedures, the screen notes that the full chain is shown below.
2. 2Why splitting helps: three concrete wins. Run on demand (workers and managers can launch each sub-procedure on its own during audits, handovers, or training), Branches that follow reality (a yes/no decision launches the sub-procedure only when it actually applies, so there are no dead steps), and Less drift, more reuse (update one procedure and every routine that uses it stays current, with no copy-pasted instructions).
3. 3What's in each workflow: the exact steps that go into the parent and each sub-procedure, card by card, so you can verify the split before deciding.

Reading the workflow cards

Each proposed workflow gets a card with rich metadata:

How the connections will work

Where a parent step hands off to sub-procedures, the screen spells out the mechanics: "After step …, the worker answers … quick yes/no questions in order:", followed by each question ("We ask: …") and what happens on If yes. There are two outcomes: either the worker runs the sub-workflow and returns to the parent, or the parent routine ends and the sub-workflow takes over.

At the bottom of the review screen, the decision footer asks: Ready to split this into … connected workflows? and notes how many sub-procedures will be extracted, each runnable on its own.

1. 1Click Generate connected workflows.
2. 2Read the confirm modal, Generate … connected workflows?. It explains the operation: the upload is split into a parent routine plus sub-workflows, with a branching step wired for each. The new workflows land as drafts you can still edit or publish. You cannot auto-merge them back, but nothing goes live until you publish.
3. 3Click Generate workflows. The button shows "Generating…" while OpsBrain builds everything in a single database transaction, so you never end up with a half-finished split.

What OpsBrain builds

• Everything is drafts. The split happens on a draft version. If the workflow was already published, the live version is copied first, so runs already in progress keep their exact steps.
• Sub-workflows are real workflows. Each child is created as its own Draft workflow, inheriting the parent's owner, category, and settings.
• Team assignments are mirrored. Every child gets the parent's team assignments, so the same workers can see and run them immediately once published.
• Steps are divided, not duplicated. The parent keeps only its own slice of steps; each child receives its slice in a fresh version of its own.
• Transition decision steps wire it together. For each connection, a yes/no decision step is inserted after the anchor step, with the "yes" answer launching the target sub-workflow. Chains work too: when a child launches its own child, the transition step is placed inside that child.
• Existing dead decisions get repaired. If the anchor step is already a yes/no decision whose answers all lead to the same place, OpsBrain merges the launch into that step instead of stacking a near-duplicate question next to it.

After you accept

You are redirected with a confirmation that matches your situation:

• If the workflow was already live: "Connected workflows generated as a new draft. The live version is unchanged until you publish the draft."
• If it was not yet live: "Connected workflows generated. Review and publish them when ready."

Sometimes a single long workflow is exactly what you want, for example when the procedures always run together in order. In that case:

1. 1Click Keep as single workflow in the decision footer.
2. 2Confirm in the modal Keep this as one workflow?. OpsBrain skips the split and takes you to the editor with everything in a single routine. The modal also reminds you that you can always re-run structure detection later from the workflow's menu.
3. 3You land in the editor with the flash message "Kept as a single workflow."

Declining is always available, on every plan, and costs you nothing: the full extracted draft is untouched.

Structure detection is not a one-shot offer tied to the moment of import:

• If you kept it as one workflow, you can re-run structure detection later from the workflow's menu, as the decline modal notes. This is handy when a workflow grows over time and starts to feel like several procedures stapled together.
• If you accepted the split, there is no automatic merge back. The confirm modal is explicit about this. To recombine procedures you would edit the drafts by hand. Since accepting only creates drafts, you can also simply not publish them and continue with the live version unchanged.

Generating a decomposition (the accept path) requires full organization access. On a trial workspace that is over its allowance, the review screen still shows you everything the AI found, but accepting is gated behind an upgrade prompt titled This process is ready to become a connected operational system. It explains that OpsBrain has identified multiple connected workflows within this process and that building the complete decomposition requires full organization access.

The secondary action, Keep workflow as one, always remains available: you can decline the split and continue with the single imported workflow at no cost.