Get Started with Salesforce Microfrontend
Learning Objectives
After completing this unit, you’ll be able to:
- Explain what Salesforce Microfrontend does and when to use it.
- Describe how the
lightning-ui-embeddingcomponent and thesf-embeddingprotocol work together. - Describe what a Multi-Framework app keeps control of when it’s embedded.
Before You Start
To follow along with this badge, it’s best if you’re familiar with building and deploying a Multi-Framework app. You also benefit from having an internal-facing Multi-Framework app that’s deployed to your org, the Salesforce DX project for that app, and Salesforce CLI available.
Salesforce Microfrontend for Multi-Framework apps is a beta service that is subject to the Beta Services Terms at Agreements—Salesforce.com or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the Product Terms Directory. Use of this pilot or beta service is at the Customer’s sole discretion.
Take Your Multi-Framework App Beyond the App Launcher
When you build an internal-facing Multi-Framework app, your users open it from the App Launcher as a full-page app. The App Launcher is the right home for a standalone experience, such as a property management app that your team uses to track rental records, approvals, and requests.
But your users don’t spend their whole day in one app. A property team often works from a Home page with their tasks and reports, or from an Experience Cloud site that the company runs for its employees. To check a listing, they open the App Launcher and switch to the property management app in another tab.
Without a way to embed the app, putting the same experience on a Lightning page means rebuilding it as a Lightning web component. Then you maintain two versions of one UI, and every change happens twice.
Salesforce Microfrontend, also called UI Embedding, solves that problem. It treats your Multi-Framework app as a microfrontend, an independently built and deployed piece of UI, and renders it in place on a Lightning Experience page or an Experience Cloud site page. You keep building your app in React or Angular, and it shows up where your users already work.
In this badge, you learn how UI Embedding works. Then you configure trust, add your app to a Lightning Experience page and an Experience Cloud site, and make the embedded app work with the page that hosts it. You can embed an app built with React or Angular, but the examples in this badge use a property management app built with React.
How Salesforce Microfrontend Works
UI Embedding loads your app inside a secure, sandboxed iframe on a Salesforce page. A base component, lightning-ui-embedding, acts as the host. You point the base component at your app, and it renders the app in the iframe.
The app and Salesforce communicate over a protocol called sf-embedding. The iframe always loads your app from a different origin than the Salesforce page. This cross-origin setup keeps the embedded app isolated from the host. When the app loads, the two sides complete a short handshake.
- The app announces that it’s ready.
- Salesforce establishes a private message channel.
- From then on, the app can respond to the host page.
Because the app runs in its own iframe on its own origin, it keeps control of its own routing, state, and styling. The host page’s styles don’t leak into your app, but you can match them, as you’ll learn in Unit 3. Your app’s client-side routes work the same way when it’s embedded. UI Embedding gives the app a controlled way to talk to Salesforce without giving up that independence.
Security works the same way it does when your app runs on its own. The app still reads and writes records through Data SDK, which Multi-Framework apps use to work with Salesforce data. GraphQL queries and mutations from Data SDK run through the User Interface API, so object-level security, field-level security, sharing rules, and validation rules still apply to the running user.
Apps That Salesforce Hosts Versus Externally Hosted Apps
UI Embedding works with two kinds of apps, based on where the app is hosted.
- App that Salesforce hosts: A Multi-Framework app is a UI bundle, which is a type of Salesforce metadata that holds the app’s source, configuration, and routing rules. For an internal-facing app, Salesforce serves it from the Salesforce app domain,
*.salesforce.app, so you don’t need to run a web server. This badge covers this kind of app. - App that you host externally: Your app runs on your own HTTPS origin, and you point the embedding component at that external URL.
The embedding component and the sf-embedding protocol are the same in both cases. The difference is where the app is hosted, which also changes some of the trust configuration.
Don’t confuse hosting with audience. Internal- and external-facing describe who uses a Multi-Framework app, either employees or customers and partners. Hosting describes where the app is served from. Salesforce hosts both internal-facing and external-facing Multi-Framework apps. An externally hosted app is one that you run on your own server.
What You Build
To embed your app, you build a thin wrapper Lightning web component. The wrapper renders lightning-ui-embedding and points it at your app. You also add one import to your app so that it can connect to the host page. Because Lightning App Builder and Experience Builder both support custom Lightning web components, creating the wrapper component is how your app gets onto a page.
Now that you know how UI Embedding works and which kind of app you’re embedding, you’re ready to put an app on a page. In the next unit, you configure trust for each surface and add the wrapper to a Lightning Experience page and an Experience Cloud site.