High-Volume Portal Users
High-Volume Portal Users are limited-access external users who carry no role and sit entirely outside the role hierarchy.
Definition
High-Volume Portal Users are limited-access external users who carry no role and sit entirely outside the role hierarchy. The design exists so an org can sign in thousands to millions of customers without the platform recalculating hierarchy access for every one of them. Salesforce documentation now files this group under high-volume community or site users.
The original license, High Volume Customer Portal, is a legacy portal license. Salesforce stopped selling it in Summer '13, and it survives only in orgs that already had a Customer Portal or Partner Portal running by then. The current equivalents are Experience Cloud licenses, where Customer Community and External Apps are the two types Salesforce still classifies as high volume.
The constraint set is what you plan around. Access reaches these users through sharing sets keyed to their profile, plus whatever the org-wide defaults already allow. Records they own travel back out to staff through share groups. Role-based sharing rules and manual sharing simply do not apply to them.
In plain English
“Imagine a building where every badge lists who your boss is, so the doors can work out which rooms you may enter. That works fine for a few thousand badges. For a million customers it would grind to a halt checking. So these badges list no boss at all, and use one simple rule instead: you can open the doors that belong to your own account.”
Worked example
Northwind Appliances runs a warranty support site for 400,000 customers on Customer Community licenses. Each customer's Contact record hangs off a household Account. The admin opens Setup, types Digital Experiences in Quick Find, selects Settings, and creates a sharing set on the Customer Community User profile. One access mapping on Case ties User.Contact to Case.ContactId at Read/Write. A second mapping on Asset ties User.Account to Asset.AccountId at Read Only. A signed-in customer now sees their own six open cases and four registered appliances, and nothing from any other household. No sharing rule exists for those records, and none of those users appears in a role. Remove the Case mapping and all 400,000 users drop to zero case visibility.
How record access works when a user has no role
The role hierarchy was the scaling wall
Every user with a role adds nodes to a tree the platform walks during sharing recalculation. Give a million portal customers roles and that tree becomes the most expensive structure in the org. Role changes, ownership changes, and group maintenance all slow down together. High-volume users solve this by not existing in the hierarchy at all. The high-volume user documentation says it plainly. These users have no roles, which eliminates the performance issues that come with role hierarchy calculations. The cost does not vanish, it moves to you, because the sharing tools you already know stop working for this population.
What the license takes away
The restriction list is longer than most admins expect on day one. A high-volume user cannot own an Account. They cannot share a record manually, and nobody else can manually share a record they own. They cannot join a personal or public group, an owner-based sharing rule, an account team, an opportunity team, or a case team. They cannot be added to CRM Content libraries or assigned to territories. Cases cannot be transferred from a member-based user to a high-volume user. Each of those is a design constraint to plan around, not a bug worth filing with support.
Sharing sets replace sharing rules
A sharing set is the declarative tool that grants these users record access. It keys off profiles, not roles or public groups. Inside it you build access mappings. Each mapping ties a lookup on the user's Account or Contact to a lookup on the target record. Then it sets Read Only or Read/Write. The path today is Setup, Quick Find for Digital Experiences, Settings, then New in the Sharing Sets related list. One trap catches nearly everyone. A sharing set on Case, Contact, or Opportunity does not carry access up to the parent Account. Add the Account mapping yourself, or your users stare at orphaned detail records.
Share groups send access the other direction
Sharing sets solve inbound access. Share groups solve outbound. When a high-volume user creates a case, internal agents cannot see it by default. There is no role above the owner for anyone to inherit from. A share group attached to the sharing set fixes that. You name the internal and external users who should see those records. You configure it on the Share Group Settings tab of the sharing set. Two warnings in the docs are worth taking literally. Activation runs asynchronously and emails you when it finishes. Deactivating strips every other user's access to those records at once. Share groups also do not cover guest users, who need guest user sharing rules instead.
The rename, and what you actually buy now
Legacy portal licenses are not on the price list. Salesforce files High Volume Customer Portal, Customer Portal Manager Standard, Customer Portal Manager Custom, and Gold Partner under Legacy Portal Licenses. Those are restricted to orgs already running a portal before Summer '13. Anything new goes on Experience Cloud licenses. Customer Community, Customer Community Plus, Partner Community, and External Apps each come in a member-based and a login-based version. External Identity and Channel Account round out the family. Customer Community and External Apps inherit the whole role-less model described above, alongside the older Authenticated Website license. The original vocabulary lingers in Trailblazer threads and in a help URL that still contains hvpu.
Designing access without a hierarchy to lean on
Plan the access paths before the data model hardens. Sharing sets can only follow lookups that already exist. A missing junction object or a missing Account lookup becomes an access problem you cannot solve declaratively. Where a mapping cannot express the rule, Apex managed sharing is the fallback, and it is considerably more work to build and test. Test with a real site user rather than an admin profile, because an admin sees everything and therefore proves nothing. Keep the exposed object list short as well. Every object you add is another mapping to maintain and another way for the site to leak.
How organizations use High-Volume Portal Users
Puts every billing dispute on Case. One sharing set maps User.Account to Case.AccountId, so each customer sees only their own service address history.
Gives 40,000 warranty registrants Read on Asset and Read/Write on Case. A share group then lets internal support agents see the cases those customers open.
Runs a grantee portal on Customer Community licenses, mapping User.Contact to a custom Grant Application lookup. Customer Community Plus and role-based sharing would cost more and add nothing.
Trust & references
Cross-checked against the following references.
- About High-Volume Community or Site Users (opens in new tab)Salesforce
- Legacy Portal Licenses (opens in new tab)Salesforce
- Create a Sharing Set for Experience Cloud Site Users (opens in new tab)Salesforce
- Use Share Groups to Share Records Owned by High-Volume Experience Cloud Site Users (opens in new tab)Salesforce
- Experience Cloud User Licenses (opens in new tab)Salesforce
- Understanding Apex Managed Sharing (opens in new tab)Salesforce
Straight from the source - Salesforce's reference material on High-Volume Portal Users.
Hands-on resources to go deeper on High-Volume Portal Users.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
+5 pts / dayQ1. Why do high-volume Experience Cloud site users have no role?
Q2. Your sharing set grants Read/Write on Case, but site users hit an insufficient privileges error on the account name shown on their own case. What is most likely missing?
Q3. Which statement about the High Volume Customer Portal license is accurate today?
Discussion
Loading discussion…