Salesforce Micro Frontend Patterns for Platform Architects

The Real Challenge for Salesforce Platform Architects

You manage a Salesforce org where different teams need to deliver features quickly. One group wants to build a product registration wizard in React. Another needs an analytics dashboard in Angular. The platform requires everything to sit inside Lightning Experience or Experience Cloud pages, pulling live record data and respecting field-level security. Rewriting every interface as Lightning Web Components creates delays and forces your frontend specialists to learn a new framework.

This tension shows up in mid-market and enterprise Salesforce implementations. Architects end up maintaining parallel codebases or accepting slower release cycles because the external app team cannot deploy independently of Salesforce releases.

Current State of Custom Frontend Work

Most teams still rely on older patterns such as Lightning Container Component shells or custom Aura wrappers. These approaches let you host an external application, yet they leave gaps in communication, theming consistency, and lifecycle handling. You end up writing custom postMessage bridges, managing your own sandbox attributes, and rebuilding styling logic whenever Salesforce updates design tokens.

The result is duplicated effort. Frontend developers maintain one version of their application for the corporate site and another version tuned for Salesforce. Updates require coordination with the Salesforce release calendar, and small changes can trigger full regression testing inside the org.

A Lighter Approach Using Salesforce Micro-Frontends

Salesforce introduced Micro-Frontends as a Developer Preview feature in the Summer ’26 release. The pattern lets you embed an externally hosted web application—built with React, Angular, Vue, or plain JavaScript—directly into Lightning pages or Experience Cloud sites. The external application runs inside a platform-managed, sandboxed iframe while the system handles data exchange, theming, and events.

This approach sits alongside the Salesforce Multi-Framework runtime. Where Multi-Framework supports native deployment of React applications as UI Bundles, Micro-Frontends focuses on embedding existing external applications as composable sections. Your React team keeps its own repository, CI pipeline, and deployment cadence. The Salesforce side only needs a thin LWC shell that references the hosted application.

You avoid the rewrite tax. The same application that runs on your marketing site can appear inside a Lightning record page with record context passed automatically through the bridge. Updates to the external application do not require a Salesforce package deployment.

How Salesforce Micro-Frontends Actually Work

A generated LWC shell component acts as the host. You install the @sf-embedding/experimental-mfe-lwc-shell package, run the vendor build command, and deploy the resulting LWC. Inside that wrapper you configure an iframe or custom element with the source URL of your external application and the appropriate sandbox tokens.

The companion MFE Bridge package runs inside the external application. It listens for platform messages that deliver record data, user context, and design tokens. The bridge also sends events back when the user saves changes or triggers navigation inside the embedded app. Three tiers of sandbox policy control what the iframe can do: base permissions allow scripts, optional flags enable forms, and blocked tokens prevent top-level navigation that could escape the Salesforce page.

You add the external domain to CSP Trusted Sites. The platform then manages auto-resizing, unsaved changes detection, and accessibility features such as keyboard navigation and screen reader support. Data flows through the bridge without requiring separate OAuth flows in most cases, because the iframe inherits the authenticated session.

This setup works on Hyperforce orgs and supports both Lightning Experience and LWR sites. The pattern aligns with the broader move toward Headless 360 architectures where the frontend can be composed from multiple sources while the core platform still enforces security and data access rules.

Practical Implementation Steps

Start in a scratch org or sandbox. Confirm that Hyperforce is active and that you have permissions to create and deploy LWCs. Install the experimental shell package and generate the vendor component with the CLI command provided in the documentation.

Next, prepare the external application. Add the MFE Bridge package and initialize it with the Salesforce context handlers. Map incoming messages to your application state and emit events when forms submit or records need updating. Test that design tokens arrive correctly so the embedded interface matches the surrounding Lightning theme.

Create a thin wrapper LWC that imperatively instantiates the shell element, sets the source URL and sandbox attributes, and appends it to the DOM. Add the wrapper to a Lightning page or Experience Builder section. Verify that record context appears, that unsaved changes block navigation, and that keyboard focus moves correctly between the page and the iframe.

Recipes in the trailheadapps/multiframework-recipes repository demonstrate data exchange patterns and event handling. Use these as starting points rather than building the bridge logic from scratch.

Honest Limitations You Should Know

The feature remains in Developer Preview. Behavior can change before general availability, and you accept the Beta Services Terms. Iframe rendering adds measurable overhead compared with native LWC components, especially on mobile connections or when the embedded application loads large bundles.

Same-origin handling and certain advanced communication patterns may require adjustments when the GA release arrives. Angular support is still emerging, and managed package distribution of the shell component is listed on the roadmap but not yet available. Performance testing with realistic data volumes remains your responsibility.

Security isolation is strong because of the sandbox policy, yet you still need to review the external application for its own vulnerabilities. The platform prevents escape from the iframe, but it does not scan the content you load.

Decision Framework: Light Embedding Versus Heavy Custom Build

Choose the Micro-Frontends pattern when your frontend team already maintains a production React or Angular application that needs Salesforce context. It also fits when release cycles must stay independent and when the interface functions as a widget or section rather than the primary navigation surface.

Move to a heavier native build with Salesforce Multi-Framework or pure LWC when the component sits at the core of the user workflow, when sub-100-millisecond interaction latency is required, or when the interface must work offline. Full custom development also makes sense if the team lacks experience maintaining external hosting and CI pipelines outside Salesforce.

Measure the update frequency first. If the external team ships weekly, embedding preserves that speed. If changes occur quarterly and the component touches many Salesforce objects, a native implementation reduces integration points and simplifies governance.

Next Steps

Review the official developer documentation for the current shell package and migration notes. Test the pattern in a non-production org before committing to a production rollout. Track the Summer ’26 release notes for updates on GA timing and expanded framework support.

Want help implementing Salesforce Micro Frontend patterns? Book an intro call to talk through your setup.