Experience Cloud portals your customers and partners actually use
Customer, partner and member portals on Salesforce Experience Cloud. Sharing model designed before the pages, knowledge wired in, AI answers grounded in your own content.
A portal is a window onto your CRM for people you do not employ
That makes it a sharing-model problem before it is a design problem. We are Salesforce implementation specialists inside an AI-first engineering firm, so we design the access rules, the pages and the answer layer as one system.
Customer self-service
Customers log cases, track orders, read knowledge and update their own details without a phone call. Deflected contacts pay for the portal.
Who logs in, what they must see and do, and which licence tier that implies. Written down and signed off before any page is built.
Sharing model
Organisation-wide defaults, sharing sets, sharing rules, guest user policy and field-level security, documented in a matrix and tested persona by persona.
Site build
LWR or Aura template, branded theme, navigation, forms and flows. Custom Lightning Web Components only where the standard components stop.
Knowledge and self-service
Data categories, article visibility for external users, search tuning and deflection flows that suggest an article before a case is created.
Identity
SSO through SAML or OpenID Connect, self-registration with approval, login and password flows, and an MFA policy that suits external users.
AI answers
Retrieval over knowledge articles, manuals and documents, with citations, built on our document Q&A services and surfaced inside the portal.
Access model
Who sees what: the decision that shapes everything else
External users never see your full CRM. They see what the sharing model lets through, and nothing else. We design that layer first because it decides licences, data model and page design together.
Persona
Typical access
Sharing mechanism
Licence consideration
Anonymous visitor (guest user)
Public knowledge, contact forms, event listings
Guest user profile plus guest sharing rules; the guest never owns records
No licence; strict least privilege; security-tested before launch
Customer (self-service)
Own cases, orders, assets, invoices
Sharing sets keyed on the user's Account or Contact
Member- or login-based external licence, sized on expected monthly logins
Partner role hierarchy, sharing rules, account-level visibility
Partner-tier licence with role-based sharing; fewer, heavier users
Event attendee or exhibitor
Registration, agenda, lead retrieval, networking
Usually a dedicated event platform synced to Salesforce
Per-attendee licences rarely make sense; integrate instead
Licence names change
Salesforce renames and repackages external licences periodically. We size the model on access needs and confirm the exact SKU with your account executive before you commit.
Architecture
How a request travels from an external user to your data
Every portal request passes the sharing layer before it touches CRM records, knowledge or the AI answer service. Get that layer right and the rest follows.
Self-service
Deflection only works if people find the answer
Most portals launch with a search box and a hundred knowledge articles, then wonder why case volume did not fall. Articles need data categories, external visibility and titles written the way customers ask. We tune all three.
Where the answer lives in a manual, a PDF or a ticket history rather than an article, we add a retrieval layer. The portal takes a plain-language question and returns an answer with citations, grounded in your content. It uses the same approach as our customer support AI solutions.
Questions that still need a human become cases with the conversation attached, ready for Service Cloud routing. Nothing is lost between the bot and the agent.
Data categories mapped to products and audiences
Article visibility set per channel, not globally
Deflection flow suggests articles before case creation
Retrieval over manuals and documents, with citations
Escalation creates a case with the full transcript
Search and answer analytics reviewed monthly
Events
Event portals: integrate, do not licence every attendee
If you run conferences, exhibitions or member events, an Experience Cloud licence per attendee is rarely the right economics. Registration, ticketing, check-in, badge printing and exhibitor lead retrieval need purpose-built tools. Our own Eventify platform covers that ground. Our registration and ticketing work then syncs attendees, sessions and scanned leads into Salesforce as Contacts, Campaign Members and Leads.
The Experience Cloud site then does what it is good at. It becomes a logged-in area for sponsors, exhibitors and partners, sharing the CRM data your sales team already works. See Salesforce integrations for the sync patterns we use between the two.
Process
From persona map to hypercare
A focused customer portal typically runs 8–14 weeks. Partner portals with deal registration and pricing logic run 12–20 weeks.
Discovery
Personas, journeys, licence estimate and a security review of any existing external access. One to two weeks.
Design
Sharing matrix, information architecture, page designs and the list of standard versus custom components.
Build
Template, theme, flows, knowledge setup, SSO and any custom LWCs, built in a sandbox with weekly demos.
Data
Contacts enabled as external users, accounts aligned to partners, articles migrated and categorised.
UAT
Persona-based test scripts plus a security pass that attempts to read other customers' data.
Go-live
Staged invitations, communications, and monitoring of logins, errors and search terms.
Hypercare
Two to four weeks of fast fixes, content tuning and adoption reporting.
What goes wrong
Five portal mistakes we fix most often
A guest user with object access it never needed, exposing records to anyone with the URL
Sharing designed after the pages were built, so every page needs rework
Knowledge without data categories, so search returns everything and nothing
A licence bought for every event attendee instead of an integration
Custom components where a standard one would have done, doubling maintenance
How long does an Experience Cloud portal take to build?
A focused customer self-service portal usually takes 8–14 weeks from discovery to go-live. Partner portals with deal registration, pricing logic and SSO run 12–20 weeks. The sharing model and data readiness drive the range more than page design does. Ask for a scoped estimate.
Which Experience Cloud licence do we need?
It depends on what each persona must see and do. Customers viewing their own cases need less than partners working shared opportunities with role-based sharing. We map personas to the lowest licence tier that supports their access and confirm the exact SKU against Salesforce's current licence guide before you buy.
Can the portal answer questions from manuals and PDFs, not just knowledge articles?
Yes. We add a retrieval layer over knowledge articles, product manuals and internal documents, and surface answers with citations inside the portal. See document Q&A for how the retrieval side works.
Should we build our event website or attendee portal on Experience Cloud?
Usually not for public events. Licensing every attendee as an external user is expensive, and registration, ticketing, check-in and lead retrieval need purpose-built tooling. We typically run events on our event technology stack and sync attendees, leads and sessions into Salesforce.
How do you keep the guest user safe?
Least privilege from the start. The guest gets no object access the public pages do not need, sharing rules are scoped to specific records, and the guest never owns records. Before go-live we run a security pass that tries to read other people's data through the API.
Ready to make AI work in production?
Tell us about your systems, your data and your constraints. We reply within one business day with a straight answer and a suggested next step.