Why This Is Useful
Salesforce CMS lets you create and manage content (articles, images, documents, news items) inside Salesforce, then publish it out to an Experience Cloud site.
The genuine appeal is that your content lives next to your customer data. Marketing manages content in the same place your service team works, and you’re not maintaining a separate WordPress install and syncing things between systems.
This post covers setting up CMS and getting that content onto an Experience Builder site, plus CMS Connect, which is the other direction entirely.
Step 1: Permissions First
Start here, because getting this wrong is where most of the confusion comes from.
Create a permission set for whoever will be creating content. Call it something like CMS User.
Now the important bit: you must assign it a permission set license. Without one you cannot grant tab access, and the CMS app won’t appear for your users no matter what else you configure.
You could do this on a profile instead, but I’m a permission set person, for all the reasons I went through in the profiles vs permission set groups post.
Grant access to the Salesforce CMS tab and the relevant CMS permissions, then assign it to your content authors.
Step 2: Create A CMS Workspace
Open the Salesforce CMS app and create a workspace. A workspace is a container for related content with its own contributors and channels.
Two things worth thinking about now rather than later:
Language. Set your default properly. Retrofitting multi-language content is considerably more annoying than planning for it.
Contributors. Who can create, and who can publish. These are separate, which is genuinely useful when you want a review step before things go live.
Most orgs are fine with one workspace. Create more when you have genuinely separate content sets with different audiences and different authors.
Step 3: Content Types
Salesforce ships a few standard types (News, Image, Document) and you can build your own custom content types with whatever fields you need.
Custom types are the feature worth knowing about. If you’re publishing product spotlights, you probably want a title, an image, a description, a price and a link, as proper structured fields rather than one big rich text blob.
Structured content is much easier to render consistently, and much easier to change the design of later without editing every piece of content.
Step 4: Channels
A channel is where content gets published to. Your Experience Cloud site is a channel, and one workspace can publish to several.
This is the bit that makes CMS worth using over just building pages by hand: write once, publish to many places. The same article can appear on your customer community, your partner portal and your public site, and updating it updates all three.
Step 5: Get It Onto The Site
In Experience Builder, first connect your CMS workspace under Settings, then use the CMS components:
CMS Single Item – one specific piece of content.
CMS Collection – a list, filtered by type or tag. This is the one you’ll use most.
CMS Content List – a browsable list with pagination.
Drag one on, point it at your workspace, choose a layout, publish. Content appears.
For anything the standard components can’t do, you can query CMS content from a custom Lightning Web Component via the ConnectApi Managed Content methods. Worth knowing that door exists, though the standard components cover most cases.
CMS Connect Is The Opposite Thing
Worth being clear about, because the names are similar and it confuses people constantly.
Salesforce CMS = content stored in Salesforce, published out.
CMS Connect = content stored elsewhere (WordPress, Adobe Experience Manager, Drupal), pulled into your Experience Cloud site.
CMS Connect is what you want when the business already has a corporate website with a real CMS behind it, and wants the community site to match. Rather than duplicating headers, footers and branding, you pull them in live. Marketing updates the main site, your community follows automatically.
Two modes: JSON for structured content from a headless CMS, and HTML for pulling in fragments like headers and footers directly.
The main gotcha is CORS. The external server has to allow requests from your Salesforce domain, and that’s usually a conversation with whoever runs it. Budget time for that rather than assuming it’ll just work.
Which Should You Use?
Salesforce CMS when content is genuinely about your Salesforce data, when your authors already live in Salesforce, or when you don’t have another CMS and don’t want to run one.
CMS Connect when there’s an established corporate CMS, a marketing team who won’t move, and a need for consistent branding across sites.
Both is entirely reasonable. Pull branding and corporate content in via CMS Connect, manage community-specific content in Salesforce CMS.
Salesforce’s CMS documentation has the full detail on both.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
