Connecting Your CMS to Salesforce Is Not the Same as Moving It There
Content has traditionally been Marketing's domain. Website infrastructure belongs to IT. Salesforce Experience Cloud sits somewhere between the two, usually implemented, operated and ultimately controlled by IT, despite being responsible for delivering experiences that Marketing is expected to own. The result is a familiar tension: the people responsible for the content and customer experience are often constrained by the technical conventions of the platform, while the CMS products they already use rarely support the Lightning architecture in the way Experience Cloud demands.
Salesforce CMS Connect exists to answer part of that problem. It lets content from an external CMS be rendered inside supported Experience Cloud sites, so the same content does not have to be copied and maintained twice. Keep content management where it already works, use Salesforce where it adds value. It is an attractive proposition.
The trap is assuming that connecting a CMS reproduces its functionality inside Salesforce. It does not, and finding that out after the architecture is approved is an expensive way to learn it. We wrote an introduction to CMS Connect in 2024. This piece is the harder conversation: where it fits, where it does not, and how to prove which side of that line you are on before you commit.
What CMS Connect actually does
CMS Connect brings external content into an Experience Builder site. Depending on the connection type, that can include:
- HTML fragments such as headers, footers and banners
- CSS and JavaScript used to style or support that content
- JSON content, as either a single content item or a content list
- shared branding and reusable content elements
- language mapping, and multiple connections per site
That makes it useful when the requirement is to display content that is managed somewhere else. A communications team can keep publishing corporate news in the existing CMS while the same articles appear in a Salesforce partner portal, without a second editorial process.
It is an integration mechanism. It is not a universal adapter that turns every feature of an external CMS into an equivalent Experience Cloud capability.
Check your site template first
Before any other design work, confirm that CMS Connect is available for the type of site you are building. Salesforce's documentation describes CMS Connect for Aura-based site templates, such as Customer Service, Partner Central and Build Your Own (Aura). Lightning Web Runtime (LWR) sites are not on that list. LWR sites use Salesforce CMS content through data binding and their own components instead.
Because new Experience Cloud builds increasingly default to LWR, this single constraint can decide the architecture. If your site is, or is going to be, LWR, CMS Connect is not the integration path, and the design needs to start from APIs or Salesforce CMS instead. Check the current Salesforce release documentation against your specific template before you plan around it.
The CMS product name is not the main issue
Integration discussions often stall on whether a particular product is "supported". Salesforce lists a small number of named CMS sources and also provides an "Other" option, and the connection itself is built on web standards and supported content formats rather than a promise of identical behaviour from every product.
That matters. A system that can serve HTML or JSON is not thereby able to expose every one of its features through CMS Connect, and it may not expose the specific content structures, endpoints or rendered fragments your Salesforce site needs. A product can be connectable without being functionally equivalent to a natively integrated platform. It is also worth being precise about what the external system is: a learning management system or a web application framework is not a CMS, even if it can emit HTML.
Start the assessment from the behaviour you need, not from the product name.
Three different meanings of "integrate our CMS"
The same sentence can hide three very different requirements.
1. Reuse content. Display existing content in another experience: a common header and footer, news articles, product information, shared branding, material owned by a central communications team. This is the straightforward case. If the CMS can expose the content in a compatible format, CMS Connect may well be the right answer.
2. Reuse content and keep the existing publishing process. Content teams keep their CMS and their workflow. Now the questions multiply. Does content update when it should? Are caching and publishing behaviour acceptable? Are languages mapped correctly? Can the CMS expose what is needed without changing how it publishes? A successful connection proves content can be retrieved. It does not prove the end-to-end publishing process behaves as expected, so that has to be tested against the real CMS configuration and the real site.
3. Reproduce the CMS experience. This is where assumptions get expensive. The expectation is that Salesforce will somehow provide the external CMS's content types and relationships, approval workflows, navigation, search and filtering, personalisation, authentication and authorisation behaviour, dynamic components, preview, scheduling and publishing controls. None of those become available because CMS Connect is configured. Some can be achieved through the CMS, Salesforce configuration, APIs or custom development. Some need a different integration pattern entirely. The question is no longer whether the systems can connect. It is whether the proposed architecture can deliver the required behaviour at an acceptable cost and complexity.
The technical constraints are part of the design
CMS Connect has specific prerequisites that belong in the design assessment, not arriving as defects during development or worse as incidents in post production verification:
- The external system must expose content over HTTPS in a compatible format.
- CORS on the CMS and the site's Content Security Policy trusted sites must be configured correctly.
- Salesforce restricts some HTML tags, attributes and more importantly sandboxes scripts, so content that relies on them may not render as expected.
- Only JSON connections can be authenticated, and authenticated JSON sources work only for authenticated users of the site. HTML, CSS and JavaScript connections must be reachable without authentication.
None of these is a reason to reject CMS Connect. They are reasons to validate the actual use case before treating the integration as a configuration exercise. A proof of concept should use real content, not a simplified demonstration page: the real content types, rendering, links, assets, languages, authentication requirements and security controls that production will need.
When CMS Connect is a good fit
It is worth evaluating when:
- the site template supports it
- the requirement is primarily to reuse or render externally managed content
- the CMS can expose that content in a compatible format
- the content does not depend on markup or scripts Salesforce restricts
- styling and JavaScript can operate inside the site's security and rendering constraints
- the organisation accepts the split of responsibility between the CMS and Salesforce
- the expected behaviour has been demonstrated with representative, production-like content
In those conditions it avoids unnecessary duplication and preserves a sensible boundary: the CMS manages content, Salesforce provides the surrounding customer, partner or service experience.
When a different approach is needed
Look at other patterns when the requirement goes beyond displaying external content: combining CMS content with Salesforce data, applying complex access rules, bespoke search, or reproducing application behaviour that belongs to the external CMS. Options include:
- Salesforce CMS, where its content model meets the requirement (and the natural route for LWR sites)
- the external CMS's APIs feeding a purpose-built Lightning Web Component
- a middleware or integration layer to transform and govern content
- separating the presentation layer from the CMS where the experience justifies it
- redesigning the content model or workflow where there is a genuine business case
Each of these has a cost. Custom components add development and maintenance obligations. Middleware is another component to operate and secure. Moving content into Salesforce can duplicate capability and disrupt established editorial processes. The goal is not the most elaborate integration. It is the least complex architecture that demonstrably meets the requirement.
A practical evaluation checklist
Before approving a CMS Connect implementation, answer these and record the answers as acceptance criteria:
| Question | What to verify |
|---|---|
| Does the site template support CMS Connect? | Confirm Aura or LWR, and check current Salesforce documentation for that template. |
| What content must be reused? | Actual content types, fields, assets and relationships. |
| How is content exposed? | Endpoints, formats and authentication model. |
| What must render in Salesforce? | Representative pages, not a single simple fragment. |
| Which CMS behaviours must remain available? | Essential requirements, separated from assumed feature parity. |
| What security controls apply? | HTTPS, CORS, CSP, authentication and access requirements. |
| How does content change? | Publishing, caching, language mapping and updates. |
| Who owns failures? | Responsibility across the CMS, the connection, the Salesforce page and supporting services. |
| What is the fallback? | What users see when external content cannot be retrieved or rendered. |
That gives the delivery team something concrete to demonstrate, and gives stakeholders an evidence-based way to decide whether the integration is fit for purpose rather than a demo that happened to work.
The short version
CMS Connect addresses a legitimate need: reusing externally managed content inside Salesforce Experience Cloud, on the site types that support it. Judge it against that purpose, not against an assumption that integration makes the external CMS's whole feature set available inside Salesforce.
A connection demonstrates interoperability. It does not demonstrate functional equivalence. Confirm the site template, define the behaviour you need, validate the technical constraints and test with real content before committing. If the requirement exceeds what CMS Connect provides, find that gap at the start and choose an architecture that closes it deliberately, rather than discovering it halfway through delivery.