Plan an Experience Cloud portal by deciding who logs in and what each audience must do there, then choose licenses and sharing to match. Customers usually need self-service and their own cases or orders. Partners need leads, deals and shared accounts. Members need their own records and content. Those answers set the license tier, the sharing model and the guest-user exposure, and they are far harder to change after launch than the page layout.
Start with the audience, not the template
Salesforce describes Experience Cloud as a way to build branded sites connected to your CRM for customers, partners or employees, and one org can run several sites for different purposes. The first planning question is therefore which people you are inviting and what they will do on a typical visit. A distributor checking order status, a reseller registering a deal and a member updating their details look similar on a wireframe, yet each one needs a different slice of your data.
| Customer portal | Partner portal | Member portal | |
|---|---|---|---|
| Typical jobs | Find answers, open and track cases, view orders or assets | Receive leads, register deals, see shared pipeline and resources | Update profile, see account or benefit records, register for events |
| Records they see | Mostly their own account, contact and cases | Records owned by their company and records you share with them | Their own records plus shared content |
| Visit pattern | Occasional, often when something goes wrong | Frequent for active partners, rare for the long tail | Seasonal or tied to renewals and events |
| Design pressure | Case deflection and clear answers | Channel conflict, data visibility between partners | Accurate personal data and easy sign-in |
Write one sentence per audience describing success, such as "a partner can register a deal and see whether it was approved without emailing us." If a sentence names data you do not keep in Salesforce today, that is an integration or data project, and it belongs in the plan before anyone designs pages.
Licensing in general terms
External users need an Experience Cloud license, and Salesforce offers several tiers for them: Customer Community, Customer Community Plus, Partner Community, External Apps, plus licenses for identity-only and channel-account use. The broad pattern is that higher tiers give access to more objects and more flexible sharing. Customer Community Plus and Partner Community users hold a role, which lets you share records through the role hierarchy and sharing rules; the basic Customer Community tier relies on sharing sets instead.
Each license can also be bought per member or per login. Member-based licenses assign a license to each person, which suits people who log in often. Login-based licenses draw from a monthly pool, with each user consuming one login per day however many times they sign in, which suits audiences who visit occasionally. Many portals have both: a small group of heavy users on member licenses and a larger group of occasional visitors on login licenses. Estimate visits per audience before you talk numbers with Salesforce, and confirm current packaging and terms with your account team.
Sharing and guest-user security
Portal security has two sides: authenticated users who should see only their own company's records, and guest users who reach public pages without logging in. Salesforce enforces some protections for guests by default, including private external org-wide defaults and read-only access at most, but the configuration choices are still yours. In March 2026 Salesforce published a set of actions for securing guest access, and they make a sensible baseline for any site.
- Set external org-wide defaults to Private on every object, then open access deliberately.
- Strip the guest user profile down to the objects and fields public pages actually render.
- Turn off guest access to public APIs and the API Enabled permission on the guest profile unless a documented feature needs them.
- Disable portal and site user visibility so visitors cannot list your staff or other members.
- Remove self-registration where it is not needed, and gate it with approval where it is.
- Check field-level security on contacts, cases, leads and custom objects that hold personal data.
- Use the Guest User Sharing Rule Access Report, then review Event Monitoring logs after launch.
For authenticated users, test with real personas rather than an admin login. Create a user for each audience and account type, then try to open another customer's case or another partner's opportunity by URL and through search. Record those tests so they can be rerun whenever someone changes a sharing rule or adds a component.
Content and self-service
For customer portals, the self-service value comes from Knowledge and case handling that already work inside Service Cloud. Salesforce positions customer sites around three routes to an answer: your knowledge base, your service agents and peer-to-peer support. The portal only exposes those; if articles are thin or out of date, publishing them externally will make that visible to customers. Decide which article types go external, who approves external wording, and how a customer escalates from an article to a case without retyping the question.
Partner portals run on different content: onboarding material, price books, marketing assets and the deal registration process. Salesforce supports sharing a pool of leads with partner users and deal registration so partners can submit qualified deals and you gain early pipeline visibility. Agree the rules for lead acceptance, deal expiry and conflict between partners before building the screens, because those rules decide the sharing model as much as the page does.
A payments ISO we worked with shows what a working portal replaces. Its 60+ independent agents had depended on separate legacy systems; after consolidation onto Sales, Service and Experience Cloud, those agents could search merchants, submit applications and track status themselves. The portal was one part of a larger platform, which is typical: the underlying records and automation have to be right before the external view is worth opening.
Rolling out a portal
Launch to a small, friendly group first. For partners that might be three resellers who already submit deals by email; for customers, a handful of accounts your support team knows well. Watch where they get stuck, which searches return nothing, and which cases still arrive by phone or email, then fix those before inviting the rest. Plan the invitation process itself, including how contacts become users, which email they receive and who handles locked-out accounts.
Set a few measures before launch so the portal can be judged on evidence: share of cases opened through the portal, article views before case creation, deals registered by partners, and active users per audience against licenses held. Assign an internal owner for the site with time to maintain content, review access and process registration requests. A portal without an owner drifts quickly, and the drift shows up first as stale content and then as over-shared data.
