A customer portal looks simple from the outside: clients log in, see their information and get help. Behind it sits a set of decisions that shape your support workload, your data exposure and your audit trail. Teams that make those decisions late often launch a portal that shows too much, invites more requests than they can handle, or can't explain who looked at what.
This guide covers the choices to settle before launching a Salesforce customer portal on Experience Cloud: whether customers can create cases, how cases from unexpected email addresses are matched, what each user can see, who can log in as a portal user, and how list views stay under control.
Before launching a Salesforce customer portal, decide five things: whether portal users can open new cases or only follow existing ones; how inbound emails from alternate addresses link to the right account; which records and fields external users can see through sharing sets and field-level security; who may log in as a portal user, and how that's audited; and who can create shared list views. Settling these early prevents data exposure and support overload. Vantage Point configures portals through its Salesforce implementation and advisory services.
A Salesforce customer portal is an Experience Cloud site where external users, such as clients, log in to see their own records. Typical portals show account details, cases, documents and status updates. Because the data lives in the same Salesforce org your staff use, the portal's settings decide exactly how much of it customers can reach.
If you're still choosing a platform, our comparison of Experience Cloud and HubSpot CMS for client portals covers that decision. This guide assumes you've chosen Salesforce and are preparing to launch.
It's tempting to add a "New Case" button by default. Before you do, ask whether your team can handle what it invites. Easy case creation often brings a flood of small, fragmented requests, some duplicating emails or phone calls already in progress.
You have three reasonable options:
| Option | How it works | Best for |
|---|---|---|
| View-only cases | Users see status and history of cases your team opens | Teams with limited support capacity or email-first support |
| Guided case creation | A form with required categories and help articles shown first | Teams ready to triage, with clear request types |
| Open case creation | Any user can open a case on any topic | Dedicated support teams with service levels in place |
Starting view-only is a sensible default. You can add a guided form later, once you know which request types customers actually need. Removing a feature customers already use is much harder than adding one.
Many cases arrive by email, not through the portal. Salesforce matches an inbound email to a contact by address. When a co-applicant, spouse, assistant or colleague writes from an address that isn't on file, the case arrives without a contact or account.
Plan for this before launch:
Portal visibility works in two layers. Record access decides which records a user can reach. Field access decides which fields on those records they can read.
For record access, customer portals commonly use sharing sets, which give a portal user access to records linked to their own account or contact. Salesforce Help explains how to create sharing sets for Experience Cloud site users. If a customer can't see their own account or ledger information, the sharing set usually doesn't cover that object or relationship yet.
For field access, use field-level security on the external user's profile or permission sets. Internal fields, such as fee calculations, internal notes, risk flags or staff comments, should be hidden rather than just left off the page layout. A field removed from a layout can still surface elsewhere if the user has read access.
Build a simple permissions matrix: one row per object, one column per user type, and a clear read, create or edit decision in each cell. Test it by logging in as a sample user of each type.
Salesforce lets authorized internal users log in to a site as a specific external user, which is useful for troubleshooting exactly what a customer sees. The Salesforce Help guide to logging in as another user covers how it works.
It's also powerful. Anyone using it sees everything that customer can see and can act as them. Treat it as a controlled privilege:
For a broader view of logging and accountability, see our guide to building audit trails in your CRM.
List views seem harmless, but a shared list view built by the wrong user can expose records to people who shouldn't see them together. The safe pattern is simple:
Sharing still controls which records appear, so list views don't bypass security. But restricting who publishes them keeps the portal predictable.
A portal home page should answer the questions customers call about most. Often that means clear status information, key dates and balances, recent activity, and an account details area showing what's on file. Avoid internal jargon, and label fields the way customers talk.
A short list of what customers ask most often, pulled from support emails and calls, is the best guide to what belongs on the home page. Revisit it a few weeks after launch.
Portals drift. New fields get added to objects customers can see, new staff get login-as rights, and a request type that was handled by email quietly becomes a portal form. Name a portal owner, usually someone in service operations working with your Salesforce admin, and give them a short quarterly review:
Vantage Point designs and launches Salesforce customer portals that customers use and teams can support. Our Salesforce implementation and advisory team builds the sharing model, case process and portal experience, and our compliance and security solutions cover permissions, auditing and data exposure reviews. We've completed 400+ engagements for 150+ clients, with a 4.71/5.0 average engagement rating and 95% client retention. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Settle the case, sharing and access decisions before customers log in. Vantage Point can review your portal setup and build a permissions model your team can stand behind. Talk to Vantage Point about your Salesforce portal.
No. A portal can show the status and history of cases your team opens without letting users open new ones. Many teams start view-only and add a guided case form later.
Salesforce matches inbound emails to contacts by address, so emails from unknown addresses arrive without a contact. Capture alternate addresses, create contacts for regular senders, and route unmatched cases to a queue for manual linking.
A sharing set gives portal users access to records linked to their own account or contact. It's a common way to control which records customers can see in a Salesforce portal.
Use field-level security on the external user's profile or permission sets. Removing a field from the page layout alone isn't enough, because a readable field can still appear elsewhere.
Only a small group, such as support managers and admins, under a clear policy. Login-as access lets someone see and act as the customer, so it should be limited and audited.
Yes. Login-as sessions are recorded in the Setup Audit Trail, which Salesforce keeps for 180 days. Export the audit trail regularly if you need a longer history.
They can if given the permission, but it's safer to let them create personal list views only. Keep shared or public list views with admins so what's shared stays deliberate.