The setup loop is Sharing Sets first, Share Groups second. Most HVPU community designs need at least one Sharing Set per external object.
- Identify external objects users need access to
List every standard and custom object the external user should see. Common picks: Cases, Orders, Assets, Custom Object My Subscriptions.
- Define Account-based sharing logic
For each object, decide the path from the HVPU user to the records. The standard pattern is Account.Id, but custom lookups can drive the path.
- Create a Sharing Set per object
Setup, Experience Cloud Workspaces, Sharing Settings, Sharing Sets, New. Pick the user profile, the target object, and the access mapping path.
- Test as the HVPU user
Log in as a community user, verify the expected records appear, verify no unexpected records appear. Iterate until the access model matches the design.
- Create Share Groups for internal-side visibility
Share Groups grant internal users access to records owned by HVPU users. Build one Share Group per internal team that needs that visibility.
- Monitor performance
Track page-load performance and SOQL query times on the community pages. Sharing Sets evaluate at query time, so poorly indexed paths cause slowdowns.
- HVPU users do not participate in role hierarchy. Sharing rules that grant access via Roles + Subordinates do nothing for these users.
- Sharing Sets evaluate at query time. Poorly indexed lookup paths cause slow page loads at scale; index the foreign keys in the path.
- Switching a user from Customer Community Plus to Customer Community Login (HVPU equivalent) loses any role-based sharing access immediately. Plan license changes carefully.
- Audit Sharing Sets and Share Groups quarterly. Drift between the design intent and the actual configuration accumulates as objects are added.