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.

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.

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.

The Current State Is Messy

Salesforce's public materials send mixed signals on availability.

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.

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.

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.

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.