Customer self-service
Case submission, status tracking, documents and a knowledge base.
Experience Cloud
A portal for customers, partners or vendors — with clear permission boundaries.
Building portals on Experience Cloud: self-service, requests, documents and status, all on top of the same data model and the same sharing rules — without opening a back door to your data.
Capability map
What's included, and in what order
Experience Cloud — Capability Map
Customer self-service
Case submission, status tracking, documents and a knowledge base.
Partner portal
Leads, deals, deal registration, materials and approval workflows.
Vendor portal
Requests, documents, approvals and payment status.
Permission model
Sharing sets, profiles and field-level exposure controls.
Identity & login
Registration, login, password reset and optional SSO.
Branding & UX
Brand alignment, accessibility and mobile support.
Background
What actually determines the outcome
A portal is an extension of your permission model, not a separate site. Every field it exposes gets checked against who's allowed to see it and what happens if it's exposed by mistake.
A portal's value is measured in reduced manual contacts. If the customer still calls to check status, the portal didn't solve the problem — it added a channel.
A successful portal starts with at most three core scenarios, and expands only after real usage has been measured.
What we do
Areas of work
Partner portal
Leads, deals, deal registration, materials and approval workflows.
Vendor portal
Requests, documents, approvals and payment status.
Permission model
Sharing sets, profiles and field-level exposure controls.
Identity & login
Registration, login, password reset and optional SSO.
Branding & UX
Brand alignment, accessibility and mobile support.
Decision matrix
The decisions that determine the outcome
| Decision | Option A | Option B | What decides it |
|---|---|---|---|
| License type | Guest access | Authenticated user | Whether personal data is required |
| Sharing model | Access to related records only | Sharing by account hierarchy | The structure of the customer or partner |
| Initial scope | Self-service only | Full transactional portal | Maturity of Salesforce processes |
| Identity | Local authentication | Enterprise SSO | Whether an identity provider already exists |
License type
- Option A
- Guest access
- Option B
- Authenticated user
- What decides it
- Whether personal data is required
Sharing model
- Option A
- Access to related records only
- Option B
- Sharing by account hierarchy
- What decides it
- The structure of the customer or partner
Initial scope
- Option A
- Self-service only
- Option B
- Full transactional portal
- What decides it
- Maturity of Salesforce processes
Identity
- Option A
- Local authentication
- Option B
- Enterprise SSO
- What decides it
- Whether an identity provider already exists
How we work
Delivery steps
- 01
Define audience & scenarios
Who logs in, what they need to do, and what counts as success.
- 02
Permission model
What's exposed, to whom, and under what conditions.
- 03
UX design
Short paths, accessibility and mobile support.
- 04
Process integration
Requests, cases or approvals that continue in Salesforce.
- 05
Security testing
Verify real-world exposure before going live.
- 06
Measurement
Usage, contact reduction and drop-off points.
Keep exploring
Related services and guides
FAQ
Experience Cloud — questions we hear often
Does a portal put organizational data at risk?
The risk exists when permissions are inferred from the design rather than the model. When sharing is planned upfront and exposure is tested before launch, a portal is no riskier than any other authenticated interface.
How long does it take to build a portal?
A focused self-service portal with two or three scenarios is much faster than a full transactional portal. The biggest factor isn't design — it's the maturity of the processes and data behind it.
What's the difference between a portal and a website?
A website shows general information; a portal shows personal data from the system and lets users act on it. The real difference is authentication and permission model, not appearance.
Can we connect an AI agent to the portal?
Yes, but only after precisely defining what data the agent can access and what it's allowed to do. In an external portal that requirement is stricter than for internal use.
Next step
Plan a portal
We'll define the audience, scenarios and exposure boundaries, and build a portal that genuinely reduces manual work.
Next step
Plan a portal
We'll define the audience, scenarios and exposure boundaries, and build a portal that genuinely reduces manual work.