ProfessorFlow
ArticleIntermediate

React on Salesforce: What Multi-Framework Means for Flow Developers

Salesforce Multi-Framework brings React to the platform. Here's why Flow developers should pay close attention — and what it could mean for the future of screen components.

April 15, 20265 min

What Just Happened

Salesforce recently announced Salesforce Multi-Framework, now in open beta. If you haven't seen it yet, the short version is this: developers can now build native Salesforce applications using React — with built-in authentication, security, and platform data access — and deploy them directly to an org using the Salesforce CLI.

That's a big deal on its own. But if you work with Flows — especially if you've ever wished for richer screen components — this is worth understanding even if it doesn't mention Flow directly. Let's walk through what it is, how it works, and why it matters for the Flow ecosystem.

Understanding Multi-Framework

To appreciate what this opens up, it helps to understand what Multi-Framework actually provides under the hood.

At its core, Multi-Framework is a framework-agnostic runtime on the Agentforce 360 Platform. Right now, React is the supported framework, with others on the roadmap. When you scaffold a new project, you get:

  • React + Vite — standard local development with hot reload, just like any modern React project
  • A data SDK — a createDataSDK() helper that gives your components access to Salesforce data through GraphQL and Apex, with authentication handled automatically
  • Salesforce CLI deployment — when you're ready, push your compiled app to any org
  • Tailwind CSS and shadcn/ui — included in the starter template, so the styling experience feels familiar to modern frontend developers

The key thing to understand here is that these aren't iframe embeds or workarounds. These are first-class platform applications that live inside Salesforce and inherit the platform's security and governance model.

Where Flow Fits In

Now here's where it gets interesting for our community.

Today, if you want a custom screen component in Flow, you build it as a Lightning Web Component (LWC). You implement the lightning__FlowScreen target, expose @api properties for inputs and outputs, and deploy it to your org. That model works — and it's given us components like datatables, file uploaders, and rich navigation elements that make Flow screens genuinely powerful.

But there are real constraints that come with that approach, and they're worth being honest about:

The ecosystem gap. The broader JavaScript world has thousands of mature, well-tested UI libraries — data grids, rich text editors, charting tools, date pickers, drag-and-drop builders. In the React ecosystem, you can install any of these with a single command. With LWC, each one needs to be rebuilt or carefully adapted as a Lightning component. That's a significant amount of effort that limits what ends up available to Flow builders.

The contributor bottleneck. React has a global developer community in the millions. LWC, while growing, is a much smaller pool. When only LWC developers can build Flow screen components, that naturally limits how many components get built and maintained. Many talented developers who could contribute to the Flow ecosystem are effectively on the sidelines because the tooling is unfamiliar.

The tooling divide. LWC has its own testing framework, its own module system, and its own development patterns. Developers coming from React, Vue, or Angular need to learn a new set of tools before they can be productive. That's not a criticism of LWC — it's just a reality of having a platform-specific framework.

Multi-Framework starts to address all three of these constraints, even if the Flow integration isn't here yet.

What Could This Look Like for Flow Screens?

Let's think forward. If Salesforce exposes Multi-Framework components as embeddable elements in Flow screens — and given the platform's trajectory toward openness, that's a reasonable expectation — several things become possible:

Access to the full React library ecosystem. Picture a Flow screen component backed by a professional-grade data grid from AG Grid, a rich text editor from Tiptap, or interactive charts from Recharts. Today, building each of those as an LWC is a significant project. With React, developers could leverage these mature libraries directly and focus their effort on the Flow integration rather than rebuilding UI primitives.

A broader contributor base. When React developers can build Flow screen components using the framework and tools they already know, the pool of potential contributors grows dramatically. Components that currently require deep LWC expertise could be built by any experienced React developer who understands the Flow component contract.

Faster development cycles. React's developer experience — hot module replacement, React DevTools, component-level testing with tools like Vitest and React Testing Library — is mature and fast. That translates to quicker iteration when building and debugging screen components.

Cleaner data access patterns. The createDataSDK() approach provides a straightforward way for components to interact with Salesforce data through GraphQL and Apex. For screen components that need to query, display, or update records, this could offer a more intuitive pattern than working with @wire decorators and Lightning Data Service.

What Hasn't Changed (Yet)

It's important to be clear about where things stand today so we're making informed decisions, not speculative ones:

  • Multi-Framework is in open beta as an app-level runtime. Salesforce has not announced support for embedding Multi-Framework components inside Flow screens. We're reading the trajectory, not the roadmap.
  • LWC is not going anywhere. Salesforce has been explicit that Multi-Framework complements LWC — it doesn't replace it. The 80+ Base Components, the deep platform integration, and the entire existing LWC ecosystem are fully supported and actively developed.
  • Flow Builder's component model still expects LWC with specific interfaces and property decorators. For React components to work in Flow screens, Salesforce would need to build a bridge between the two models. That's technically feasible, but it's not trivial.

If you're building Flow screen components today, LWC remains the right choice. It's production-ready, fully supported, and well-documented.

Why This Matters for the Community

Zoom out for a moment and look at the pattern. Salesforce has been steadily opening the platform to the broader developer ecosystem: Agentforce brought AI agents and natural language automation. Experience Cloud expanded frontend flexibility. Now Multi-Framework brings React.

Each of these moves lowers the barrier to entry for developers who want to build on Salesforce. For the Flow community specifically, that trend is encouraging. The more accessible it becomes to build screen components, the richer the component library grows — and the more powerful Flows become for everyone, including admins who never write a line of code.

Whether you're a developer, an architect, or an admin who works closely with developers, here's how to stay ahead of this:

  1. Explore the beta. Even a quick walkthrough of the Multi-Framework starter project will give you a feel for the developer experience and help you form your own opinion about its potential.
  2. Continue investing in LWC. Your existing screen components and LWC skills aren't at risk. LWC is the supported, production-ready path for Flow today, and that's not changing.
  3. Follow the release notes. Watch for any announcements about Multi-Framework + Flow integration in upcoming Salesforce releases and TrailblazerDX sessions.
  4. Start thinking about what you'd build. If you could use any React library in a Flow screen, what components would make the biggest difference for your users? Having that wishlist ready means you can move quickly when the capability arrives.

Looking Ahead

Salesforce Multi-Framework represents the most significant shift in how developers build on the platform since LWC was introduced. For those of us in the Flow ecosystem, it opens up a future where the gap between what modern web development can do and what Flow screens can show begins to close.

We're not there yet — but the foundation is being laid. And understanding that foundation now means you'll be ready to build on it when the time comes.

Search

Search components, articles, and tags