React Inside Salesforce Multi Framework and Agentforce

Agentforce makes the React conversation inside Salesforce feel concrete.

Agents need places to work. A chat panel helps, but real work still touches records, permissions, approvals, search, data quality, business rules, and old process debt. The UI matters because that is where the human sees the agent's suggestion, judges the context, changes the data, and moves the work forward.

Salesforce already owns much of that surface. Reps, service teams, admins, partner users, and operations groups spend their day there. Salesforce Multi-Framework addresses a practical platform request: modern React apps can now live closer to that work surface.

When you think about it, a team has never needed Salesforce approval to build in React. They can open Visual Studio Code, start a Next.js app, deploy to Vercel, call Salesforce APIs, and move quickly. And at the end of the day, for many public web products, that remains the cleaner path.

Multi-Framework gets very interesting when an app should behave like part of Salesforce: launched from Salesforce, governed by Salesforce access, deployed through Salesforce metadata, and grounded in the same org context Agentforce needs.

To me, Multi-Framework is a Salesforce-hosted UI artifact model for React. That's a mouthful, I know. But that's exactly it. Multi-Framework belongs in the architecture conversation for Agentforce work surfaces, internal apps, and focused portal utilities. It should stay out of reflexive "move the web app into Salesforce" thinking.

The Agentforce Use Case Is the Cleanest Starting Point

Start with a service operations team that needs a case triage workspace. The screen shows account context, related cases, entitlement status, suggested actions, and an Agentforce conversation panel. A rep asks the agent for help, accepts a next step, updates a field, calls an Apex-backed action, and moves on.

The center of gravity is Salesforce. The data, identity, permissions, and action surface all live there.

In that setting, React inside Salesforce makes a lot of sense. Salesforce's own docs say Multi-Framework apps can include org data, CMS content, search, authentication, and the Agentforce Conversation Client. Internal apps can open through the App Launcher on desktop and Salesforce mobile.

That is a real product idea: build a modern React interface for a Salesforce-native workflow, then let Salesforce host and govern the UI artifact.

What Salesforce Is Hosting

A Multi-Framework React app becomes a UIBundle.

This bundle lives inside a Salesforce DX project under
force-app/main/default/uiBundles/{app_name}.

The folder holds metadata, runtime configuration, source code, and compiled assets. .uibundle-meta.xml tells Salesforce what the app is and where it can run. ui-bundle.json describes output directories, routing, redirects, rewrites, and SPA fallback.

After deployment, Salesforce creates the UIBundle record, establishes app identity, and declares the containers that can host it. Salesforce CMS stores runtime assets and metadata with a publication lifecycle.

For internal users, the target is CustomApplication, which makes the app available through the App Launcher. For external users, the target is Experience, which creates a site or portal through Digital Experiences. Although, as we just covered, Multi-Framework is best used for internal apps.

The browser still runs the React code. The unusual part is packaging, hosting, identity, and context. The app becomes a Salesforce-recognized artifact served from Salesforce-controlled surfaces, with a path back into Salesforce APIs.

So to keep it simple: React source builds into assets, assets get wrapped in UIBundle metadata, Salesforce serves the artifact, the browser executes the app, and the app talks back through supported paths such as the Data SDK, GraphQL, UI API, Apex REST, or approved services.

This is artifact hosting. Full-stack application hosting still belongs somewhere else when the experience needs server-side rendering, route handlers, webhooks, long-running jobs, or server-held secrets.

The Server Question

The public Multi-Framework docs I reviewed describe compiled assets, routing, redirects, rewrites, output directories, and SPA fallback. They describe a client-side app model with Salesforce platform integration.

I found no documented UIBundle equivalent of Next.js route handlers, React Server Components, ISR, arbitrary Node functions, edge functions, webhook receivers, or server-held secrets. And that fact right there defines the lane for Multi-Framework. A dashboard, console, account workspace, portal utility, or agent-assisted task flow may live comfortably in that lane. It can use authenticated Salesforce data, Apex-backed logic, and a clean React UI.

A public commerce storefront lives in a different lane. Storefronts need product discovery, SEO, fast category pages, server logic, cart orchestration, checkout, payment handling, tax, shipping, ERP connections, observability, and cache strategy. Integrations with payment, ERP, and shipping systems also belong away from browser code.

The key distinction is straight forward: Salesforce work surface versus web product backed by Salesforce APIs. Multi-Framework fits the first pattern. Next.js, Vercel, middleware, or a similar web stack still fits the second.

Modern Dev Tools Can Build This Too

Any modern dev tool that supports MCP servers, project rules, reusable context, and repository-local instructions can support this framework.

Salesforce publishes Salesforce-centric skills optimized for Agentforce Vibes, and those skills can inform any AI tool that supports this kind of context. Nowadays skills can be adapted and converted as needed.

At XCentium we have been using the same pattern for eight months: give an agent Salesforce CLI access, org context, repository rules, skills, documentation, test commands, and a careful workflow. After that, it can do serious Salesforce work because the context is real.

Of course whatever dev tool you use, it needs the same setup discipline: Salesforce DX structure, CLI access, an MCP server or equivalent org access, project rules that explain UIBundle, Data SDK, metadata targets, and deployment constraints, plus tests that run in the actual repo. It also needs a habit of retrieving metadata before inventing objects, fields, relationships, or permissions.

With those pieces in place, modern tools can build a React app meant to run inside Salesforce. It can edit components, write tests, refactor state, improve accessibility, update ui-bundle.json, and help maintain the DX project.

The tool choice matters less than context discipline.

The Current State Is Messy

Salesforce's public materials send mixed signals on availability.

The April 2026 developer launch blog described Multi-Framework as open beta for scratch orgs and sandboxes, with beta apps barred from production. Current setup docs list supported editions. A Summer '26 Salesforce blog labels Multi-Framework as GA. Other surfaces still expose UIBundle (Beta) language.

Before any production architecture decision, check the target org. Confirm Multi-Framework availability, app domain setup, bundle deployment, license coverage, packaging rules, release process, and rollback path.

Security and Governance

Salesforce's product pitch leans on inherited authentication, backend scale, security, and governance. That is definitely a good business reason for Multi-Framework.

However, the React security story still needs care.

Salesforce's React-vs-LWC guidance is more sober than the product page. LWC has deeper native platform integration and built-in platform security patterns. React gives flexibility, while React security and secure API calls remain developer responsibilities. In other words buyer beware. Don’t expect Multiframework to have all the security bells and whistles of LWC.

Multi-Framework can keep the app inside Salesforce governance. Teams still need to review npm dependencies, client-side logic, API exposure, error handling, and data access.

The Data SDK Helps (With Some Caveats)

The Data SDK is one of the more practical pieces of the architecture. It handles authentication, CSRF tokens, base path resolution, GraphQL, and a fetch wrapper for supported Salesforce endpoints. For Salesforce-native apps, it removes plumbing.

The boundary appears when the app needs APIs outside the documented list. The supported endpoint list I reviewed includes Apex REST, selected UI API endpoints, selected Connect and Chatter endpoints, telemetry, CSRF, session, and logout paths. Salesforce Commerce REST endpoints were absent.

For B2B Commerce you have to plan a bridge explicitly: Apex REST, middleware, or future Salesforce support. This will take some research which I have not completed yet.

Experience Builder and Admin Control

Salesforce says Experience Builder editing is unavailable for React Experience Cloud sites.

That limitation matters because Experience Builder is part of the usual Salesforce value story. Admins can adjust pages, components, audiences, layouts, and content without a developer in the loop. React UI Bundles shift more ownership back toward developers. And I have seen many developers welcome the power this gives them. After all Experience Builder is not the same as code access.

That trade can work for a focused portal workflow. For ongoing business-user composition and content control, LWC or standard Experience Builder patterns may fit better. Its best to call that differentiator out with the business while evaluating Multi_Framework.

Best Fits

The strongest use cases share a pattern: authenticated users, Salesforce-owned data, Salesforce-owned actions, and a UI that benefits from React.

An internal Agentforce case console is a good example. The rep already works in Salesforce. The agent needs record context. The actions call Salesforce logic. The app can launch from App Launcher. Public SEO, payments, and webhooks sit outside the scope.

A sales planning workspace also fits: Account, Opportunity, Contact, Activity, and Data Cloud signals in a React view, with an agent that summarizes account history or suggests next actions. A partner portal utility can fit when the Experience Cloud limits are acceptable. Think request status, record search, guided support, or partner operations.

A useful early pilot / eval is a narrow internal workflow. Pick one Agentforce touchpoint, one user group, one object family, one deploys path, and one test plan. Have your best dev tools take a swing and then look at metadata accuracy, test quality, deployment clarity, and failure modes.

Weak Fits

A typical public B2B Commerce storefront is the weak candidate. It needs product discovery, SEO, fast category pages, server-side logic, cart orchestration, checkout, payment handling, tax, shipping, ERP connections, observability, and cache strategy. Some integrations should never run from browser code.

If you really want to push it you could take a look at a Salesforce-hosted React companion application – an Account dashboard. Order lookup. Reorder helper. Sales-assist workspace. Partner operations console. But it’s a stretch at this point and would likely over complicate things.

The storefront itself should stay in a full-stack web architecture unless Salesforce documents the missing runtime pieces and proves the path in the target org. Marketing sites and integration-heavy operational apps deserve the same caution. Use the stack that provides the right content workflow, analytics, backend endpoints, and operational controls.

My Current Take

Salesforce Multi-Framework is a serious answer to a real pressure point. Salesforce developers want modern UI patterns. Web developers want better interfaces around Salesforce data. Executives want AI-assisted delivery without losing governance. Agentforce needs UI surfaces where human action and agent recommendations can meet. And most importantly Agentforce needs performant systems supporting it. LWC is slower than React. T

The optimistic outlook on this story can be compelling: React for the interface, Salesforce for identity and data, Agentforce for the work assistant. However, in a pessimistic version there are plenty of chances for error when moving React directly into SF.

My recommendation is practical. Use Multi-Framework for Salesforce-native work surfaces, especially internal Agentforce apps and focused portal utilities. Keep public storefronts, web-heavy experiences, webhooks, server-side orchestration, and SEO-driven pages on a web architecture built for that job.