Workflow Tracer

The Workflow Tracer follows a Bubble workflow from its trigger all the way through custom events and backend API workflows, so you can see a whole chain in one picture instead of clicking through the editor.

What to upload

A full Bubble application export. See get your app export out of Bubble.

The parser needs at least one of pages, element_definitions or api. A database-only schema file has none of them, so it will be rejected with "Invalid Bubble JSON format. Expected workflow data."

It also reads user_types and option_sets to turn internal identifiers into the names you actually see in the editor, and settings to resolve plugin action names and API Connector call names.

The upload screen. One file, and every workflow in the app becomes traceable.

Where workflows come from

Bubble keeps workflows in three places, and the tracer reads all three:

Page workflows — attached to a specific page, under pages.
Reusable element workflows — attached to a reusable, under element_definitions.
Backend API workflows — under api.

Pick a container in the left drawer, then pick a workflow inside it. The search box matches container names and workflow names, which is usually quicker than expanding the tree.

A loaded app before anything is selected: 47 containers holding 756 workflows and 1,426 actions, and 330 edges that cross from one container into another.

Reading a trace

A workflow is drawn as its trigger followed by its actions in order. Where an action schedules or triggers another workflow, the chain continues into it, so a "Button clicked" workflow that triggers a custom event which schedules a backend workflow shows up as one connected diagram rather than three separate ones.

Five actions from one button click. Step 2 only runs when the condition above it holds, and the two custom events it triggers sit collapsed to the left, one node each with its action count.

A triggered workflow is drawn collapsed, as a single node naming the event and how many actions it holds, like Custom Event: delete account (4). The prefix is Reusable: when the event lives on a reusable and API: for a scheduled backend workflow. Collapsing them is what keeps a chain running through several workflows readable on one screen. Click the node to expand its actions inline and click it again to collapse; selecting a different workflow collapses them all again.

A page-load workflow with three triggered events collapsed beside it. The prefix tells you where each one lives: `Custom Event:` for an event on this page, `Reusable:` for one that belongs to a reusable, and the number in brackets is how many actions it holds.

Conditions are drawn on the chain rather than hidden in a panel: the amber box is the action's Only when, with the YES path continuing down and the NO path breaking away dashed. Plugin actions carry the plugin name.

API Connector steps are stored in the export as bare apiconnector2-<connector>.<call> identifiers, so the tracer resolves them against settings.client_safe.apiconnector2 and shows the call's real name on the canvas. Select one and the detail panel opens an API Call section with the connector, the HTTP method, and the parameters that are set on the call definition rather than at the call site.

The tool detects loops and circular chains, which are the usual cause of a workflow that runs far more often than anyone intended.

Page Load Workflows

Page Load Workflows, in the left drawer's Actions section, answers a different question: not what one workflow does, but everything that fires when a given page opens. Pick a page from the selector and you get its own Page is loaded workflows, followed by those of every reusable nested inside it, at any depth. Exit puts you back in the normal view.

That list is tedious to assemble by hand, because Bubble stores each reusable's page-load workflows with the reusable rather than with the page that places it, so nothing in the editor shows you the whole set at once.

Include "Do when condition is true" widens the tree to the Do when condition is true workflows in those same containers. They are not page-load events, which is why they are off by default, but they live on the page too, so the count usually jumps when you turn it on.

Click a workflow in the tree, or its card on the canvas, to open that workflow's own diagram.

Trigger Tree view

The node-tree icon in the detail panel switches to a Trigger Tree centred on the current workflow. It answers two questions at once:

What launches this? Drawn to the left, in violet.
What does this launch? Drawn to the right, in green.

A workflow that triggers itself is drawn as a red loop arc with a count badge. Edges that fire more than once carry a ×N. Click any node to re-root the tree on it, and click the icon again to go back to the diagram.

Node colour encodes two dimensions: frontend versus backend, and ordinary workflow versus custom event.

The same workflow as a trigger tree. Nothing launches this one, since a user clicks it, so the left side is empty and the two custom events it launches sit on the right.

Triggered By

The detail panel lists what triggers the current workflow, one row per source workflow with a ×N badge where a single source triggers it from several actions. This mirrors what Bubble's own trigger panel shows.

A caveat about sanitized exports

The JSON Sanitizer strips settings.client_safe.plugins, which is the key this tool reads to turn plugin action identifiers into readable plugin names.

A sanitized export still traces perfectly. Plugin actions just show raw identifiers. Use the original file when working locally, and the sanitized one when sharing.

Errors

"Invalid Bubble JSON format. Expected workflow data." — the file has no pages, element_definitions or api. You probably uploaded a database-only schema.
"No workflows found in the uploaded file." — the file is a valid export, but nothing in it defines a workflow.

Full list in upload errors, decoded.