Salesforce Multi-Framework, announced at TDX 2026 and now in open beta, lets you build native React apps that run on the Agentforce 360 Platform with the same sharing rules, CRUD, and FLS your LWC already respects. It is additive, not a replacement. LWC is not going anywhere. The real work for architects is knowing when to reach for React and when LWC is still the better call, and setting that guardrail before your teams start picking on vibes alone.
In This Article
Here is a conversation I have had more times than I can count. A team lead walks in with three strong React developers, a shipping deadline, and a Salesforce project. And the first two weeks get spent teaching those React developers Lightning Web Components. Decorators. Wire adapters. SLDS. The base component library. Good people, slowed to a crawl, relearning things they already knew how to do in a framework they already knew.
That tax is what Multi-Framework just removed.
Announced at TDX 2026 and now in open beta, Multi-Framework is a framework-agnostic runtime on the Agentforce 360 Platform. It lets you build native Salesforce apps in React, running on the platform, with authentication, security, and governance already wired in. Not React bolted on through an iframe or a Visualforce hack. Native. Your GraphQL queries respect sharing rules. Your data calls honor CRUD and field-level security. The platform is still the platform.
Before this, using an open-source library on Salesforce meant wrestling it into a static resource and giving up platform features. React developers were a hiring bottleneck, not an asset. Multi-Framework changes the math: the global React talent pool can now build on Salesforce without a months-long detour through LWC first.
Salesforce’s front-end story has moved in long, deliberate steps. Visualforce in 2008. Aura in 2015. LWC in 2019, built on real web standards and eventually open-sourced. Each was a genuine step up. But every one of them was Salesforce-only. You learned the framework to build on the platform, full stop.
Multi-Framework breaks that pattern for the first time. React is not the endgame either. Vue, MCP UI, and A2UI are on the roadmap. React just happens to be the door that opened first, and it is a big door.
Anyone can host a React bundle somewhere and call a few APIs. That is not what this is. The whole point is that the React app runs as native platform metadata and inherits the org’s security model without you writing a line of auth code.
Salesforce treats your entire React project as a new metadata type called a UI Bundle. You generate a starter app, and it comes preconfigured with a real toolchain: the Multi-Framework SDK for platform access, Vite for bundling, Vitest for testing, shadcn/ui for components, and Tailwind for styling. If you have shipped a React app in the last three years, none of this is foreign.
The @salesforce/sdk-data package queries and mutates records through GraphQL. It manages requests so your app stays inside API limits instead of hammering the org.
The createDataSDK() utility handles authentication automatically. No token juggling, no refresh logic, no secrets in your React code. This is the part that usually goes wrong, and it is gone.
Call Apex methods directly through the SDK for server-side logic that goes past simple CRUD. Your existing business logic stays where it is and stays callable.
Every GraphQL query and mutation runs against the org’s sharing rules, object-level security, and field-level security. React does not get a bypass. The platform still decides who sees what.
That last card is the one to sit with. When a React component asks for records, it does not get a private side channel to the database. It goes through the same permission checks an LWC component would. Your security model is doing the work, not the framework. For an architect, that is the difference between a toy and something you would actually approve for production.
Data access works through a GraphQL query shaped like the UI API you already know: an object, its edges, its nodes, the fields you name. If you have written a GraphQL query before, you can read a Multi-Framework one on sight. Fetch a list of Cases, map them, render them. The auth you would normally sweat over is already solved before you type the first hook.
The mistake I already see teams making is treating this as a winner. React won, LWC lost, rip it all out. Wrong read. This is an expansion of the toolkit, not a replacement, and the orgs that get value from it will be the ones that decide, on purpose, which tool fits which job.
Here is how the two actually line up.
- Data access through GraphQL, Apex invocation, and UI API
- Bring your own components: shadcn, MUI, Ant Design, or an internal design system
- Style with Tailwind, CSS Modules, or any CSS-in-JS you like
- Full npm, Vite, Vitest, and React DevTools tooling
- Best when: your team is React-strong or components are shared across Salesforce and non-Salesforce surfaces
- Declarative data with
@wireand Lightning Data Service caching - 80+ Salesforce base components out of the box
- SLDS tokens and classes built in, accessibility baked into the compiler
- Full drag-and-drop Lightning App Builder support with property panels
- Best when: admins configure pages, you want App Builder placement, or you need LDS caching
The Two Questions That Actually Decide It
Strip away the feature lists and the choice comes down to two questions. First: who maintains this after launch? If the answer includes admins dragging components onto record pages in App Builder, that points to LWC, because React placement in App Builder is not there yet. If the answer is a developer team owning a standalone app, React is on the table.
Second: does this UI live only on Salesforce, or does it need to show up elsewhere too? A component you want to share across a Salesforce app and an external portal is a React story. A component that reads and writes standard record fields inside Lightning Experience is still an LWC story, and a good one.
Do not let this become a religious war on your team. LWC has 80+ base components, LDS caching, and native App Builder placement that React cannot match yet. React has the ecosystem and the talent pool. Write down which surfaces use which framework, and why, before anyone opens Vibes. That one page of guidance will save you a year of drift.
The React-on-Salesforce story does not stop at “you can write React now.” Agentforce Vibes 2.0 generates Multi-Framework React apps from plain-language prompts. Describe a dashboard showing open Opportunities by stage, and Vibes produces the React code, the GraphQL queries, and the Salesforce metadata to back it.
The tooling around it is genuinely useful. React and Apex templates to scaffold from, a Salesforce MCP server to pull and deploy metadata straight from the IDE, live preview as you build, and the Einstein Trust Layer keeping your prompts and responses out of model training. For getting a working app in front of stakeholders on day one, this is a real speed jump.
Now the part nobody puts on the slide. When generating a working React app drops from days to minutes, the volume of code your org has to review, secure, and maintain goes up, not down. Speed does not remove the review. It moves it, and it makes skipping it tempting.
Vibes-generated React is still React you own forever. If five teams each vibe up their own dashboard with their own component library and their own query patterns, you have not saved time. You have bought yourself five codebases to reconcile later. Governed generation, shared templates, and a review gate are not optional overhead here. They are the thing that keeps speed from turning into sprawl.
Used with a house style and a review step, Vibes is a strong accelerant. Used as a free-for-all, it is automation sprawl with better syntax highlighting. The tool is fine. The discipline around it is the architecture.
I like this feature. I am also not going to pretend it is production-ready everywhere, because it is not, and finding that out mid-project is expensive. Here is what to know before you commit a roadmap to it.
Beta apps cannot deploy to production orgs. Scratch orgs and sandboxes only, English default language.
No drag-and-drop placement for React components in Lightning App Builder. Planned for GA.
Some platform APIs are not available in the beta runtime. Check the beta docs for the current list.
The production limitation is the big one. You can prototype, demo, and pressure-test with real sandbox data, but you cannot ship to production yet. So this belongs in your evaluation and internal-tools track right now, not on the critical path for a customer-facing launch this quarter.
The Micro-Frontend Question
A lot of the excitement is about embedding React components inside existing Lightning pages as micro-frontends, sitting next to your LWC on the same record page, sharing the platform’s data and permission layer. That is the pattern most enterprise teams actually want. It is also the least mature piece. Micro-frontend support is in early preview, with the full drag-and-drop experience targeted further out on the roadmap.
So if your plan depends on dropping React islands into Lightning Experience pages tomorrow, slow down. Standalone React apps are the beta that is live today. The embedded story is coming, but coming is not shipped.
Do not let a slick TDX demo turn into a production commitment. Standalone React apps in sandbox: try them now. Production customer apps and embedded micro-frontends: put them on the roadmap, watch the release notes, and hold the line until the beta tag comes off. The gap between demo and GA is exactly where projects overpromise.
If you lead a Salesforce practice, the wrong reaction to this is a migration plan. There is nothing to migrate. Your LWC works, keeps working, and stays the right tool for a large share of what you build. The right reaction is smaller and smarter: run a real pilot and write the rules before your teams write them for you.
The UI layer on Salesforce is entering a genuinely plural period. LWC is not going anywhere. React is now a first-class native option. And the Agentforce experience layer adds a third dynamic where agents assemble interfaces on the fly. Knowing which tool fits which job is turning into a core architectural skill, not a matter of taste.
So here is the question I would put to any team evaluating this right now. Not “should we use React?” The better one: if a new React developer joined your team on Monday, how long until they ship something real on your org? For the first time, the honest answer might be measured in days. That is the shift worth paying attention to.
createDataSDK() utility handles authentication automatically, so there is no token management in your React code. Data flows through GraphQL queries and Apex calls, and every request respects the org’s sharing rules, CRUD, and field-level security. The framework does not get a bypass around your permission model.