Does Workflow Builder execute the workflow?

The short answer is no. And that’s not a weakness — it’s the point.

Workflow Builder is a frontend-first SDK. It gives you the visual editor, the drag-and-drop canvas, the property sidebars, and the ability to design workflows your users can understand. What it doesn’t do is run those workflows. Execution, persistence, and orchestration? That’s the job of your backend.

This separation of concerns is deliberate. It means Workflow Builder doesn’t force you into a rigid backend model. Instead, it outputs clean JSON that your backend can parse, store, and execute however you want. In other words, it gives developers the freedom to connect workflows to their own stack, on their own terms.

Integration is where the real value is unlocked. Done right, you get workflows that look native in your app and run natively in your system. Done poorly, you risk spaghetti integrations, lost data, and frustrated users. Here’s how to do it right.

Understand Workflow Builder’s frontend-only role

At its core, Workflow Builder is built on React and React Flow. It delivers the entire user-facing experience for workflow design: the canvas, the node library, the property panel, the drag-and-drop interactions.

Every workflow you build in the editor is represented as JSON. This JSON describes:

• The nodes on the canvas.
• The connections between them.
• The properties attached to each node.

That’s it — and that’s everything. JSON is your contract between the frontend and the backend.

Because Workflow Builder is backend-agnostic, it doesn’t dictate how you store or run that JSON. You decide. Some clients connect it to orchestration engines like Prefect or LangFlow. Others run workflows against custom Node.js or TypeScript APIs. The flexibility exists because there are “so many different tools to integrate with” that one-size-fits-all backend logic would only get in the way.

Key takeaway: don’t expect Workflow Builder to be a workflow engine. Expect it to be the best frontend SDK you can plug into your backend.

Saving, exporting, and importing workflows

If JSON is the contract, saving and loading it properly is your side of the deal.

Saving workflows

When a user creates or modifies a workflow, Workflow Builder generates its JSON representation. To “save” it, you need to send that payload to your backend and store it in your database or object storage.

In the demo version, any changes you make are saved in your browser’s local storage. There’s no backend connection, but you can still explore the full flow of saving and exporting diagrams. Real saving logic is always implemented on the client side.

Exporting workflows

Exporting looks a lot like saving. The frontend generates JSON; your backend decides what to do with it. Maybe you create a downloadable file. Maybe you send the payload to another API. Maybe you generate a PDF snapshot for compliance. The point is, Workflow Builder won’t do this for you — because every company’s export rules are different.

Importing workflows

To import, you do the opposite: take a stored JSON definition from your backend and feed it back into the frontend. Workflow Builder parses it and rebuilds the diagram.

For programmatically generated workflows, this matters even more. If your system creates workflows on the fly, Workflow Builder includes an auto-layout feature that can organize nodes vertically or horizontally. That way, even a 200-node diagram doesn’t look like spaghetti when it loads.

Version control

One of the most overlooked aspects of integration is version control. Don’t just overwrite workflows in storage. Store them with version history, like you would code. This is critical for auditing, debugging, and compliance-heavy processes like accounting.

Mini-checklist for persistence

• Do we have a schema for workflow storage?
• Can we restore older versions quickly?
• Does our import logic use auto-layout for readability?

Backend integration patterns

Once you’re saving and loading workflows, the next step is executing them. This is where backend design matters.

Consuming JSON output

Your backend services should treat Workflow Builder’s JSON as instructions. A node might represent “Send email,” with parameters for recipients and subject. Your backend consumes that JSON and runs the actual email-sending logic.

Orchestration engines

Many teams integrate Workflow Builder with orchestration layers already in their stack. Examples from real-world projects:

• Prefect: often used in data and AI-heavy environments, such as Open Patho’s digital pathology workflows.
• Windmill and LangFlow: common for agent orchestration and real-time automation.
• Custom APIs: plenty of clients build their own microservices that execute actions based on workflow definitions.
• Node.js/TypeScript: a good fit given Workflow Builder’s frontend is also JavaScript-based.

Workflow Builder doesn’t replace these engines — it complements them by providing the visual layer.

Custom actions and triggers

Workflow Builder lets you define custom node types on the frontend. You might create:

• A “Send Slack message” action.
• A “Generate purchase order” trigger.
• An “AI model inference” node.

But remember: these only capture configuration data in JSON. The execution lives in your backend. If a node says “POST this payload to /api/orders,” your backend has to implement the actual logic for that API call.

API connectivity

This pattern shows up often:

1. User drops a “Make API call” node onto the canvas.
2. In the property sidebar, they configure endpoint, URL, method, parameters.
3. Workflow Builder outputs JSON with those values.
4. Your backend reads that JSON and makes the call, handling auth, retries, and error management.

Opinionated stance: never let the frontend execute sensitive API calls directly. That’s a security hole waiting to happen.

Best practice insight: design your backend to treat workflow JSON as instructions, not code. That way, you maintain security, consistency, and auditability.

Debugging, runtime transparency, and enterprise needs

One of the most common follow-up questions is: “Can users see workflows running in real time?”

Right now, Workflow Builder is an editor. It doesn’t run workflows. Which means runtime transparency — logs, execution status, performance monitoring — is on you.

Many clients solve this by building a console-style interface alongside Workflow Builder. They run workflows on their backend, capture logs, and display “results per step” in their own UI. Visualizing workflow execution status is also possible, but it requires custom implementation: something our team at Synergy Codes can support.

The roadmap for Workflow Builder includes adding runtime visualization: highlighting nodes on the canvas as they run, showing status directly in the editor. But until that lands, execution UIs are a backend responsibility.

For enterprise projects, this also means:

• Logging every execution run with timestamps.
• Validating workflows before execution (catch schema errors early).
• Surfacing errors visually (red borders on nodes, snackbars for user notifications).
• Handling performance at scale (thousands of nodes, nested sub-processes).

Opinionated callout: Don’t underestimate runtime UX. Execution visibility is what makes workflows feel trustworthy to end-users.

Support, sessions, and real-world integration help

Even though Workflow Builder is frontend-first, backend integration can be complex. That’s why Synergy Codes provides support on top of the SDK.

• Custom development services: offered on a time-and-material basis after estimating scope. If your team doesn’t want to build an orchestration layer from scratch, Synergy Codes can help.
• Technical sessions: their developers can walk you through the codebase, JSON payloads, and best practices for backend alignment.
• Documentation: repositories and payloads are included with the license.

For many clients, these sessions are what accelerates integration from theory to production.

Sidebar: Common mistakes to avoid

1. Treating Workflow Builder as a workflow engine. It’s not. It’s the editor.
2. Skipping version control. Overwriting workflows without history = audit nightmare.
3. Hardcoding API calls in the frontend. This breaks security and compliance instantly.
4. Reinventing orchestration. Use proven engines (Prefect, LangFlow, etc.) instead of building fragile schedulers.

Conclusion: integration is where value is unlocked

Workflow Builder doesn’t claim to be the full automation stack. And that’s precisely why it works so well. It gives you the best possible frontend — a polished, customizable editor that your users love. But the real power comes from how you integrate it.

Best practices are clear:

• Save, export, and import workflows as JSON, with proper version control.
• Treat JSON as instructions, not code. Execution always belongs in your backend.
• Use orchestration engines or APIs that fit your stack; Workflow Builder doesn’t lock you in.
• Leverage vendor support when integration gets tricky.

Companies that embrace this split — Workflow Builder for the frontend, their own backend for execution — build automation that feels native, secure, and scalable. Companies that don’t risk choosing a tool with its own way of executing workflows: one that might not fit their specific use case and could lead to costly integration work.

Integration isn’t an afterthought. It’s the stage where Workflow Builder stops being a canvas and becomes a competitive advantage.

‍