Experience Cloud Development
Customer, partner and member portals built on Experience Cloud, with sharing and guest access designed carefully and custom components where configuration runs out.
Experience Cloud lets you give people outside your organisation a secure view of your Salesforce data: customers checking orders and raising cases, partners registering deals and accessing resources, members updating their details. Done well, it removes a large share of routine emails and calls. Done carelessly, it can expose records to the wrong people, because an external site is a window into your org.
We design and build Experience Cloud sites for organisations that want a portal tied directly to their CRM, rather than a separate web application that copies data back and forth.
Who this is for
- Service teams that want customers to log in, see their cases and orders, and find answers before contacting support.
- Channel and partner teams that need deal registration, lead sharing, partner onboarding and shared resources.
- Membership and education organisations that want members or students to manage their own records and applications.
- Platform owners with an existing site that has grown slow, inconsistent or difficult to secure.
What we build
Site design and templates
The right template for your needs, typically LWR-based for performance and modern development, or Aura where specific features require it.
Custom components
Lightning Web Components for experiences configuration cannot provide, built to work in the site context.
→Self-service
Case submission, case history and knowledge search for customers, connected to Service Cloud.
→Partner features
Deal registration, lead distribution and partner account management with the right sharing.
Forms and processes
Screen flows embedded in pages for applications, registrations and updates.
→Integrations
Data from order, billing or product systems shown in the portal without copying everything into Salesforce.
→Security comes first
Most serious Experience Cloud problems are sharing problems. We design access before we design pages:
- Guest users (people who are not logged in) get the minimum access the public pages require. Guest user access is restricted by Salesforce's secure defaults, and we keep it that way rather than opening objects broadly to make a page work.
- External users see records through sharing sets, share groups, account relationships or explicit sharing, chosen per object. We document why each record is visible to whom.
- Licences determine what external users can access. Customer and partner licence types differ in capabilities such as role-based sharing, so the licence choice is part of the design, not an afterthought. Confirm current licence capabilities with your Salesforce account team.
- Apex used by the site runs with sharing enforced and checks field and object access, so a custom component never shows more than the user is allowed to see.
- Authentication uses your existing identity provider through SSO where possible, or Salesforce's login, registration and password reset flows configured for your brand.
Before go-live we test as each persona: a guest, a customer user, a partner user, and a user from a different account who should see nothing of the first account's data.
How a site project runs
- 01
Personas and journeys
We define who uses the site, what they need to do, and what they must never see. This drives both page design and the sharing model.
- 02
Access design
Licence types, sharing approach, guest access and authentication agreed and documented before any pages are built.
- 03
Experience design
Page structure, navigation and branding, using standard components first and custom LWC only where needed.
- 04
Build
Configuration, components, flows and integrations in a sandbox, under version control and with code review.
- 05
Persona testing
Functional, security and performance testing as each persona, plus accessibility checks against WCAG guidance.
- 06
Launch
User provisioning or self-registration, communications to external users, and monitoring of login and error rates after launch.
What you receive
| Deliverable | What it contains |
|---|---|
| Access design | Personas, licence choice, sharing model and guest access, with the reasoning recorded |
| Site build | Configured Experience Cloud site, templates, navigation and branding |
| Custom code | LWC and Apex with tests, deployed through your release process |
| Test evidence | Persona-based test results, including negative access tests |
| Admin guide | How to add pages, manage users, update content and review guest access |
Dependencies and what we need from you
We need brand guidelines and content owners for site pages, decisions on which data external users may see, access to the identity provider team if you use SSO, and the relevant licences in place for testing. If the portal shows data from other systems, the owners of those systems need to be involved early, because their APIs and performance shape what the portal can offer. See LWC data patterns for how we approach data access in components.
Questions we hear
Should we build a portal in Experience Cloud or as a custom web app?
Can you fix an existing site that has become slow?
How do you make sure customers only see their own records?
Can the site match our main website's branding?
Plan your portal
Tell us who the portal is for and what they need to do, and we can recommend a site approach and access model.
