Experience Cloud implementation · CloudX
Experience Cloud portals: customer, donor, applicant and supplier portals on Salesforce
CloudX is an Israeli consultancy that builds portals on Salesforce Experience Cloud. A portal gives customers, donors, applicants, participants, suppliers and partners secure access to their own data, straight from Salesforce, with nothing typed in twice. We design the permission model, choose the external user license, build the screens and processes, and test every role against written scenarios. When the need is forms and documents rather than a full portal, we also build on Titan.
What Experience Cloud is and what it covers
Experience Cloud is Salesforce's product for building sites and portals for people outside your organization. The portal runs on the same Salesforce org and the same data, so whatever an external user updates lands directly on the record your team works on.
Experience Cloud includes a site builder (Experience Builder) with templates, standard and custom components, external user management, permissions and sharing, login options and support for multilingual sites.
Which portals we build on Experience Cloud
| Portal type | For whom | What the user does |
|---|---|---|
| Customer and support portal | Business and consumer customers | Opens cases, follows status, reads knowledge articles, updates details |
| Donor portal | Donors and funders | Sees donation history, updates details and payment methods, receives documents |
| Applicant and participant portal | Program applicants, scholarship recipients, participants | Applies, uploads documents, follows stages and tasks |
| Grant applicant portal | Nonprofits and grant seekers | Submits an application, updates the budget, files interim reports |
| Supplier portal | Suppliers and contractors | Updates details, submits documents, sees orders and statuses |
| Partner portal | Resellers and business partners | Registers leads and deals, gets materials, follows performance |
Customer portal
The most common portal. It connects to Service Cloud: the customer opens a case and follows it, finds answers in the knowledge base, and the service agent works on the same record. We define what an unauthenticated visitor sees and what a logged-in user sees, and each customer sees only their own organization's cases.
Donor portal
Nonprofits and foundations want to give donors one place to see their giving, update details and receive documents, without staff answering every request by email. The portal reads directly from donation data in Salesforce, so there is no separate list to maintain. More on donation and grant management in Salesforce is on the Salesforce for nonprofits page.
Applicant and participant portal
Social programs, scholarships and training programs move each participant through stages: application, screening, training, placement and follow-up. An applicant portal lets each participant see where they stand, what is missing and what comes next, while staff work on the same record inside Salesforce.
Supplier and partner portal
Suppliers update their details and submit documents, and partners register leads and deals that land directly in Sales Cloud. Data is entered once, instead of someone copying it from an email.
What CloudX builds on Experience Cloud
- Permission model: who sees which records and fields, by user type and organization. This is the critical part of any portal, and we design it before the screens.
- User management: creating portal users from existing contacts, activation from the record, access resets and a report of who has logged in and who has not.
- Screens and processes: Flow-based forms, custom Lightning Web Components, document upload and a task dashboard for the user.
- Content and knowledge: Knowledge articles, documents and updates by audience.
- Languages: Hebrew and English portals, with right-to-left layout tested in custom components.
Portal permissions and security
A portal opens Salesforce to people outside the organization, so security is the foundation, not a final step. We work by a few rules:
- Minimal guest access: an unauthenticated visitor sees only what was explicitly granted.
- Separation between organizations: each user sees only their own organization's records, through sharing settings and Sharing Sets depending on the license type.
- Testing by role: every user type runs written scenarios before go-live, including attempts to reach data that is not theirs.
- Login: as needed, username and password, a one-time code, or single sign-on (SSO).
The AI layer
A portal is a natural channel for an AI agent. An Agentforce agent can answer customers in the portal from the knowledge base and hand the conversation to a human agent when a person is needed. In application and document portals, AI can read the documents users upload and flag what is missing for staff, while the decision stays with a staff member.
Integrations
- Payments: donations and payments from the portal, recorded on the donor or customer record.
- E-signature and documents: generating a document from portal data and signing it.
- Your website: linking from the site to the portal, or website forms that feed Salesforce.
- Other systems: ERP, finance systems and integration platforms such as Workato.
Experience Cloud or Titan
Not every external need calls for a full portal. When the need is forms, documents and signatures on top of Salesforce, Titan is often the faster route.
| Consideration | Experience Cloud | Titan |
|---|---|---|
| Fits | An ongoing portal where users return, track and manage | Forms, documents, signatures and focused portals |
| User management | External users with licenses and roles | One-time code or ID-based login, per project |
| Permission model | Salesforce's full sharing model | Controlled by project settings and queries |
| Build | Experience Builder, Flow and LWC | Titan's visual builder |
We build on both platforms, so the recommendation rests on the need, not the tool.
Adoption: getting external users to use the portal
External users have had no training and are not obliged to use the portal. So it has to be clear from the first screen: what is my status, what is missing, what do I do now. We build a task dashboard, emails with a direct link, and a report showing staff who has not logged in yet, so they can reach out directly.
How a portal project runs
- Mapping: who the external users are, what each needs to see and do, and what stays internal.
- License and permission model: by number of users, login frequency and the data they need.
- Screens and processes: forms, documents, tasks and notifications.
- Build in a sandbox: site, components, Flows and permissions.
- Role-based testing: written scenarios for every user type, including separation tests.
- Go-live: gradual user activation, with clear communication.
- Support: improvements based on real usage, and ongoing support.
Choosing a portal partner: what to ask
- How do they design permissions? A good partner starts from the permission model and separation tests, not from the design.
- Which license do they recommend, and why? The license type drives both cost and what can be built, and the choice should be justified by user volume.
- Do they test every role? Written scenarios for every user type, including attempts to reach other users' data.
- Do they know the alternatives? Sometimes a focused form on Titan beats a full portal, and a partner who builds on both will tell you.
- What happens after go-live? User activation, support for their requests and improvements based on usage.
At CloudX, the answers to these questions are settled during mapping and go into the design document.
What drives cost
- External user licenses: Salesforce offers several external license types that differ in sharing and data access capabilities, and some are priced per member while others are priced per login. Choosing the right one is among the biggest cost decisions in the project.
- Number of user types: each adds screens, permissions and testing.
- Process complexity: multi-step forms, documents, signatures and payments.
- Languages: a bilingual portal needs content and testing in both languages.
- Integrations and AI: each connection or agent adds a phase.
Experience Cloud and the other Salesforce clouds
A portal is only as strong as the data behind it. A customer portal relies on Service Cloud, a partner portal on Sales Cloud, and a donor or grant applicant portal on the data model described on Salesforce for nonprofits. The full picture of our work is on the Salesforce implementation page.
Need a portal where customers, donors or applicants work directly with Salesforce? Book a call and we will map who your users are and what each one needs to see.
Work we have done
Education nonprofit · In production
Student mentoring program with an Experience Cloud portal
The program places university students as mentors in schools in exchange for a scholarship, and each student passes through intake, an assessment center, training, a placement desk and travel reimbursements. We built the full journey in Salesforce, with an Experience Cloud portal for candidates and participants, including access activation, and a five-role permission model so each team sees only its part. Before go-live every role ran 35 written scenarios. Each student's journey, from application to placement and reimbursement, now lives on one record every team works from.
Software company · In production
Support portal with knowledge and case creation
The company wanted customers to reach support and knowledge content through a portal instead of email. We worked on the portal and on Knowledge, including displaying knowledge content in the portal, adapting case creation and setting guest user permissions, so an unauthenticated visitor sees only what is allowed. Behind the portal we adapted the case processes in Service Cloud and worked on Entitlements and Milestones. Customers find an answer or open a case in the portal, and the team handles it against defined response times.
Organization running a portal on Salesforce · In production
One-click portal user activation from the record
Creating a portal user for a contact took several manual steps, and staff who are not admins could not do it. We built a Lightning Web Component with a button that runs an existing Flow to create a community user, and added it through Experience Builder with deployment instructions. Staff now activate portal access from the record, through the same process and rules every time.
Philanthropic foundation · In production
Bilingual grants portal on Titan and Salesforce
When the need is forms and documents, Experience Cloud is not always required. The foundation wanted the nonprofits it supports to apply, update budgets and report in one place, in Hebrew and English. We built on Titan a four-step application and a portal with a task dashboard, My Applications and My Grants, reading and writing Salesforce directly, and the same project is embedded inside Salesforce for foundation staff. Mapping the portal surfaced a path through which one organization could reach another organization's data, and we closed it. Nonprofits now apply and report through the portal.
FAQ
Who builds Salesforce customer portals in Israel?
CloudX is an Israeli consultancy that builds portals on Salesforce Experience Cloud: customer and support portals, donor portals, applicant and participant portals, and supplier and partner portals. We design the permission model, build screens and processes, and test every role against written scenarios. Portals are built in Hebrew and English.
What is Salesforce Experience Cloud?
Experience Cloud is Salesforce's product for building sites and portals for people outside your organization, such as customers, partners, donors and applicants. The portal runs on the same Salesforce org and data, so whatever a user updates lands directly on the record your team works on. It includes a site builder, external user management and permissions.
Can we build a donor portal on Salesforce?
Yes. A donor portal on Experience Cloud reads directly from donation data in Salesforce, so donors see their history, update details and receive documents without staff answering every request by email. We set permissions so each donor sees only their own data, and connect a payment system when needed.
How long does it take to build an Experience Cloud portal?
A focused portal with one user type and one process can go live within a few weeks. A portal with several user types, multi-step forms, documents and two languages usually takes a few months. Most of the time goes into permission design and role-based testing, which is exactly where you should not cut corners.
How much does an Experience Cloud portal cost?
Cost depends on the number of user types, process complexity, languages and integrations. External user licenses are separate: Salesforce offers several types that differ in sharing capabilities, and some are priced per member while others are priced per login. We help you pick the license type by user volume and login frequency.
Experience Cloud or Titan for a portal?
Experience Cloud fits an ongoing portal where users return, track and manage, with Salesforce's full sharing model. Titan fits forms, documents, signatures and focused portals, and often goes live faster. CloudX builds on both, so the recommendation rests on the need.
How do you make sure portal users cannot see other people's data?
We design the permission model before the screens: minimal guest access, sharing by organization and Sharing Sets depending on the license type. Before go-live every user type runs written scenarios, including attempts to reach data that is not theirs. In a portal we built for a foundation, mapping found such a path and it was closed.
Does Experience Cloud support Hebrew?
Yes. Experience Cloud supports multilingual sites, including Hebrew. We build portals in Hebrew and English and test right-to-left layout in custom components, which is where most issues appear.
How do external users log in to the portal?
As needed: username and password, a one-time code sent by email or phone, or single sign-on (SSO) with the organization's identity provider. Unauthenticated visitors see only public content that was explicitly granted. We choose the login method by user type and data sensitivity.
Can we build an applicant or supplier portal on Salesforce?
Yes. An applicant portal lets each applicant or participant apply, upload documents and see which stage they are in. A supplier portal lets suppliers update details, submit documents and see statuses. In both cases data is entered once, directly into Salesforce.
We have an existing portal that does not work well. Can it be improved?
Yes. We start by reviewing the permission model, user management and processes, and build a prioritized fix plan with permission issues first. In most cases the existing portal can be improved without a rebuild.
Last updated: