Composite App
A Composite App is a Salesforce architecture pattern where one application combines native Salesforce code (Apex, LWC, Flow, page layouts) with external functionality (a third-party web app, a Canvas-rendered service, a microservice called through External Services, or a Heroku-hosted process).
Definition
A Composite App is a Salesforce architecture pattern where one application combines native Salesforce code (Apex, LWC, Flow, page layouts) with external functionality (a third-party web app, a Canvas-rendered service, a microservice called through External Services, or a Heroku-hosted process). The user sees a single experience inside the Salesforce UI, but the runtime crosses platforms.
Composite App is one of three Salesforce architecture archetypes alongside Native App (everything runs on the Salesforce platform) and Web App (everything runs externally and uses Salesforce only as an API). It is the pattern most large enterprises end up with, because few real applications fit cleanly into one bucket: customer data lives in Salesforce, AI inference runs on a Python service, billing lives in a SaaS, and the user wants one screen that pulls from all of them.
How a Composite App stitches native and external pieces together
The three Salesforce architecture archetypes
Salesforce architecture materials describe three deployment patterns. Native Apps run entirely on the Salesforce platform: every UI screen is a Lightning component or Visualforce page, every data store is a Salesforce object, every business logic block is Apex or Flow. Web Apps run entirely outside Salesforce: the UI is on a separate domain, the data store is a separate database, and Salesforce is just an API source. Composite Apps mix the two. Most enterprise deployments are Composite Apps even if no one calls them that.
Canvas Apps and how they embed external UI
Canvas is the original Salesforce framework for embedding external web apps inside a Salesforce page. The external app runs on its own server, but Salesforce wraps it with a signed request that includes the current user identity, the org context, and an OAuth token. From the user perspective, the external app looks like just another panel on the Salesforce page. Canvas is older than Lightning Out and is still common in legacy Composite Apps.
External Services and the API-driven integration path
External Services lets a Salesforce admin import an OpenAPI specification, generate a set of Apex-callable actions, and invoke external microservices from Flow without writing Apex. In a Composite App, External Services is often what connects a native Salesforce screen to an external billing service or AI inference endpoint. The result is a single Flow that touches both worlds.
Lightning Out and the reverse-embed pattern
Lightning Out is the inverse of Canvas: it lets you embed Lightning Web Components or Aura components inside an external web app. A Composite App built around an external portal can use Lightning Out to render Salesforce-native UI inside the external page, so the user sees the same components whether they are on the Salesforce site or on the partner portal.
Heroku and the long-running process pattern
For Composite Apps with heavy compute or long-running workflows like large file processing, ML training, or third-party webhook receivers, Heroku is often the external execution layer. Heroku Connect mirrors Salesforce objects into a Postgres database, the Heroku app reads and writes Postgres, and changes sync back. The user sees a Salesforce screen, but the work happens off-platform on infrastructure that does not count against Salesforce CPU or heap limits.
Identity and single sign-on
A Composite App has to look like one app even though it runs in two places. Salesforce Identity provides SSO through SAML and OpenID Connect so the user authenticates once. The Salesforce session token, signed Canvas request, or short-lived OAuth token then travels to the external piece so the external code knows who the user is and which org they belong to. Without SSO, the user has to log in twice, which breaks the unified-experience promise.
When to pick Composite over Native or Web
Native is the right answer when all the data, logic, and UI fit naturally on Salesforce and the team has Salesforce skills. Web is the right answer when the app barely needs Salesforce and the team has web-development skills. Composite is the right answer when neither side wins: customer data already lives in Salesforce, but the differentiated capability (AI inference, complex pricing, real-time collaboration) is better built and operated outside Salesforce. Composite is the most common pattern and the most operationally complex.
How to plan and ship a Composite App
Building a Composite App means picking an integration pattern for each external piece, wiring identity, and choosing where each capability runs. The technical work is straightforward; the design work decides whether you ship in three months or eighteen.
- Catalog the capabilities and where each one runs best
List the screens and the business capabilities behind them. Mark each as native (fits Salesforce platform), external (better off-platform), or shared (needs both). This is the inventory the rest of the design works from.
- Pick the integration pattern for each external capability
For UI embedding, Canvas or an iframe. For API calls from Salesforce to external, External Services or Apex Callout. For external calling back into Salesforce, REST API or Streaming API. For data mirroring, Heroku Connect or a custom ETL.
- Set up identity and SSO
Configure Salesforce as an Identity Provider (or as a relying party if you have an external IdP). Issue OAuth scopes for the external app. For Canvas, register the Canvas App in Setup and configure the signed request keys.
- Build the integration surfaces
Develop the LWCs that embed external apps through Canvas. Generate External Services Apex actions from the OpenAPI specs. Stand up Heroku apps with Heroku Connect mappings. Test each integration in isolation before stitching together.
- Wire the unified UI
On the Salesforce side, assemble Lightning App Pages that drop in the LWCs alongside native components. On the external side, use Lightning Out to embed native components in external pages. The user should not be able to tell where one ends and the other begins.
- Test for failure modes
Composite Apps fail in ways native apps never do. Test what happens when the external service is down (graceful degradation, not a broken page), when SSO tokens expire mid-session, when Heroku Connect sync lags, and when an external endpoint changes its OpenAPI spec.
- Composite Apps double the operational surface area. You need monitoring for both Salesforce and the external pieces, plus the integration in between.
- Salesforce session timeouts and external session timeouts are independent. A user can be logged into one and out of the other without realizing it.
- Canvas requires a signed request and HTTPS on the external app. Localhost development needs a tunneling tool like ngrok.
- External Services has a 2MB request and response limit. Bulk operations need a different pattern (Bulk API, Heroku Connect, or async messaging).
- Heroku Connect sync is not real-time; default sync intervals are 10 minutes. Plan UI patterns around eventual consistency, not strong consistency.
Trust & references
Straight from the source - Salesforce's reference material on Composite App.
- External ServicesSalesforce Help
- Heroku Connect DocumentationHeroku Dev Center
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Composite App in Salesforce?
Q2. Which Salesforce feature is commonly used to embed external web apps in Salesforce pages?
Q3. When does a Composite App approach make sense?
Discussion
Loading discussion…