Skip to content
New to Superprocess? The guided invoice walkthrough takes you from a blank canvas to a running workflow.Get started

BPMN basics

Every process diagram you see in Superprocess is a BPMN diagram. BPMN — Business Process Model and Notation — is a standard visual language that’s been around since 2004 and is widely used by analysts to describe business flows. The platform uses it for a few specific reasons: it’s recognisable to anyone with operations experience, it’s expressive enough to model real processes without escaping into code, and it forces clarity about who does what when.

You don’t need to know BPMN to start using the designer — the palette only exposes the elements you need, and the platform validates as you draw. But knowing the language makes diagrams faster to read and faster to build.

BPMN has dozens of element types in its full spec. In practice five categories cover almost every diagram you’ll build:

The five element types — events, activities, gateways, sequence flows, and a lane
Category Shape What it represents
Event Circle Something happens — a trigger fires, a timer elapses, an error is raised
Activity Rounded rectangle Work gets done — a step in the process
Gateway Diamond A decision point — the flow branches or joins
Sequence flow Arrow One element follows another
Lane Horizontal band Groups elements by who or what is responsible

The first three are nodes; sequence flows are the edges that connect them; lanes are an optional grouping mechanism.

Events mark moments in time. There are three positions in the diagram:

  • Start events kick the process off. They live at the beginning of a flow and carry a trigger configuration — when this happens, start the process. An invoice flow’s start event might be configured as “email arrives in invoices@yourcompany.com with a PDF attachment.”
  • Intermediate events happen partway through a flow. The most common are timers (“wait 24 hours” or “fire on the 1st of the month”) and signal receivers (“pause until the legal-review service confirms”).
  • End events terminate the flow. A process can have multiple end events — one per branch — and each can carry a different semantic (“ended successfully,” “ended with error,” “ended because of cancellation”).

A small icon inside the circle distinguishes the event’s type at a glance: an envelope for message events, a clock for timer events, a triangle for signal events, a circle for none/plain.

Activities are where work happens. The types you’ll use most in Superprocess:

  • Service tasks — automated work the platform runs without a human. A service task binds to an AI agent (extract invoice fields) or a connector operation (post to the ledger).
  • Script tasks — run a function: a reusable snippet of custom Python (format a date, run a calculation), chosen from the Functions library.
  • User tasks — work that requires a person. The platform creates a task in the inbox, optionally shows the assignee a form to fill in, and pauses the process until the task is completed. See Tasks and human-in-the-loop for what happens then.
  • Business rule tasks — evaluate a DMN Decision (a table of rules) and write the result back into the process, keeping rule logic out of gateways and prompts.

Call activities (running another process as a sub-flow) and manual tasks round out the set; the designer’s palette lists them all.

Gateways are the decision points where one flow becomes several, or several flows merge back into one. Three gateway types cover almost everything:

  • Exclusive gateway (diamond with an X) — pick exactly one outgoing branch based on a condition. “If amount under $10K and PO matched, auto-approve; otherwise, route to human.”
  • Parallel gateway (diamond with a +) — fan out to multiple branches at once, then later wait for all of them to finish. “Check vendor in master, check budget, check duplicate — all three in parallel — then proceed when they’re all done.”
  • Event-based gateway (diamond with a hexagon) — wait for one of several events; whichever arrives first wins. “Wait for either approval or 48-hour timeout.”

A gateway is one of the few BPMN constructs where the shape inside the diamond matters. Mixing types up is a common beginner mistake; the designer’s validator will flag it.

Sequence flows are the arrows. Each arrow has a source element and a target element, and means after the source completes, the target runs next.

Arrows out of an exclusive gateway carry a condition expression — a boolean evaluated against the process instance’s variables. The platform follows the arrow whose condition is true. One outgoing arrow can be marked default, used when no other condition matches.

Arrows out of activities are unconditional — work moves to the next step automatically when the activity finishes.

Lanes are horizontal bands across the diagram. Each lane represents a role, a department, or a system. Elements drawn inside a lane belong to that role.

Lanes are presentational — they don’t change the runtime behaviour. But they make a diagram dramatically more readable when the work crosses team boundaries. “AP clerk does this, then the system does that, then AP manager approves, then accounting posts.”

For small single-role processes lanes are unnecessary. For anything involving handoffs, lanes are the difference between a clear diagram and a tangle.

Standard BPMN doesn’t know about AI agents, connectors, or forms. Superprocess adds a small set of properties to standard elements — without changing their shapes:

  • A service task binds to an AI agent (pinned to a specific published version, so a run’s behaviour can’t shift underneath it) or a connector operation.
  • A script task binds a function — a published Python function from the library.
  • A user task binds a form for the assignee to complete, and an assignment strategy (offer-and-claim, round-robin, random, or least-loaded) for how the work is routed to a group.
  • A business rule task binds a DMN Decision.

Because the extensions live on properties rather than shapes, a diagram still reads cleanly to anyone who knows BPMN. A reader who doesn’t know the extensions just sees “this is automated work” or “a person does this” — the right level of abstraction.

A well-built BPMN diagram tells a story. Read left to right, top to bottom. Start at the start event (circle on the left), follow arrows through activities, branch at gateways, end at terminal events (thicker-bordered circle on the right).

When you open someone else’s process for the first time:

  1. Find the start event. What triggers this thing?
  2. Trace the happy path. From start to end event, follow the most likely arrows. What does success look like?
  3. Look at the gateways. Each one is a branching decision. What are the conditions? What’s the default?
  4. Note the user tasks. Where does this process pull in humans?
  5. Spot the parallel work. Any + gateways? Those signal concurrent execution — useful for understanding latency.

A few minutes spent reading a process this way before you start changing it usually saves an hour of debugging.