Skip to content
Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionarySService Cloud Portal
ServiceIntermediate

Service Cloud Portal

The Service Cloud Portal is a retired Salesforce portal that gave customers self-service access to their support cases, Knowledge content, and account information through a branded web portal tied to a Service Cloud org.

§ 01

Definition

The Service Cloud Portal is a retired Salesforce portal that gave customers self-service access to their support cases, Knowledge content, and account information through a branded web portal tied to a Service Cloud org. It ran on the High Volume Customer Portal user license, which was built to support very large numbers of external self-service users at a low per-user cost.

Salesforce stopped offering new Service Cloud Portal licenses with the Summer '13 release. Only orgs that already had the portal can keep using or buying those licenses. New self-service portals are built on Experience Cloud (formerly Communities) instead. If you read about the Service Cloud Portal today, treat it as legacy history and plan any new work on Experience Cloud.

§ 02

How the Service Cloud Portal worked, and why it was retired

What the Service Cloud Portal actually was

The Service Cloud Portal was one of several legacy Salesforce portal types that let a company expose part of its org to external users. This particular flavor was aimed at customer support. Logged-in customers could open new cases, check the status of existing cases, read Knowledge articles or Solutions, and update some of their own contact and account details. Everything happened against the same case and contact records that internal agents worked in the Salesforce desktop, so a customer self-service action and an agent action touched one shared data model. The portal was branded so it looked like part of the company's own website rather than a generic Salesforce page. Administrators controlled what portal users could see through profiles, sharing rules, and portal-specific settings. Because the portal was tied to Service Cloud, its main job was case deflection: answer common questions with self-service content and forms so fewer customers needed to phone or email a live agent. It predated the modern Lightning and Experience Cloud stack, so its look and customization options feel dated by current standards.

The High Volume Customer Portal license model

The thing that set the Service Cloud Portal apart from the older Customer Portal was its license. It used the High Volume Customer Portal user license, sometimes labeled the Service Cloud Portal license. The whole point of that license was scale at low cost. A consumer-facing support site might have hundreds of thousands of customers, and giving each one a full Salesforce seat would never make financial sense. The high-volume license was priced and metered for that reality, often sold in blocks of logins per month rather than as a fixed named user. In exchange for the lower cost, high-volume users got a restricted feature set and a sharing model designed for huge user counts. They could not own records in the normal way, and access was granted through sharing sets and sharing groups rather than the role hierarchy that regular users sit in. That kept the data model performant when the user population was enormous. Today the same high-volume need is met by the Customer Community license on Experience Cloud, which carries the modern equivalent of that scale-friendly sharing approach.

Why and when Salesforce retired it

Salesforce drew a clear line in the Summer '13 release. From that point, the legacy portal licenses, including Customer Portal, Partner Portal, and the Service Cloud Portal, were only available to organizations that already had them. New orgs could no longer turn these portals on. The official guidance is direct: use Experience Cloud sites instead. The reason was consolidation. Salesforce had been running several overlapping ways to build external sites, and each had its own setup, branding limits, and quirks. Communities, which later became Experience Cloud, was the single platform meant to replace all of them. Rather than keep investing in four separate aging portal products, Salesforce funneled new development into one modern framework. Orgs with an existing Service Cloud Portal were not force-migrated overnight, which is why some long-running orgs still have these licenses in place. But the product stopped evolving. New features, templates, and components shipped to Experience Cloud, not to the old portal. That makes the Service Cloud Portal a maintenance-only relic for the orgs that still run it.

What replaced it: Experience Cloud self-service

Experience Cloud is the current way to build a customer self-service portal on Salesforce. It is the rebrand of Communities and covers customer, partner, and employee sites from one platform. For the support use case the Service Cloud Portal handled, you build an Experience Cloud site, often from a help-center or customer-account template, and add components for the jobs customers care about. A Contact Support form creates cases in Salesforce. Knowledge components let customers search articles and deflect cases before they are ever filed. Case list and case detail components let customers track open issues. Account and order components give B2B customers visibility into their relationship. Modern sites can run on Lightning Web Runtime for speed and are responsive on mobile out of the box. You assign external users a community license such as Customer Community for high-volume self-service, or Customer Community Plus when users need more sharing and reporting. The net effect is the same goal the old portal chased, self-service that lowers support volume, delivered with current tooling, branding control, and integration with the rest of Service Cloud.

Where it fits among the other legacy portals

It helps to see the Service Cloud Portal next to its siblings, because the names blur together. The Self-Service Portal was the oldest and most limited customer support portal, and it stopped being available for new orgs back in Spring '12. The Customer Portal was the broader successor that supported richer customer access and custom objects. The Partner Portal did the same job for channel partners and resellers. The Service Cloud Portal was essentially the high-volume customer support variant, leaning on the High Volume Customer Portal license to serve very large audiences cheaply. All four were retired for new orgs and rolled into a single replacement. When you audit an older org, you may find more than one of these still configured, sometimes with active users. Knowing which is which tells you how a given external user got access and what license is paying for it. It also tells you the migration target is the same in every case: rebuild the experience on Experience Cloud and move users onto the matching community license before the legacy setup becomes a liability.

What to do if your org still has one

If you inherit an org with a live Service Cloud Portal, do not panic and do not build anything new on it. Start by inventorying what exists. Find the portal users and their license type, the profiles and permission sets that grant access, the sharing sets that expose records, and any custom code or Visualforce pages wired into the portal. Capture the customer-facing journeys that matter, such as opening a case, checking status, and reading Knowledge. Then plan an Experience Cloud build that recreates those journeys with current components. Migration is rarely a flip-the-switch event, so most teams stand up the new site in parallel, validate login, case creation, and Knowledge search, then cut customers over in a controlled window. Pay attention to authentication, because portal and Experience Cloud sites handle single sign-on and self-registration differently. Watch your license counts during the transition so you are not double-paying for both stacks longer than needed. Finally, update any internal documentation and runbooks. The goal is to leave the legacy portal behind cleanly, with no customer-facing surprises and a supported platform underneath your self-service experience.

§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Service Cloud Portal.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

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 was the Service Cloud Portal in Salesforce's product history?

Q2. Which modern Salesforce platform replaces the retired Service Cloud Portal?

Q3. Should a team build a brand-new self-service portal on the legacy Service Cloud Portal today?

§

Discussion

Loading…

Loading discussion…