Building the Salesforce customer portals requires considering different tools based on the business goals.
I've been working on various Salesforce partner and customer sites during my career, ranging from co-investment platforms and self-service portals to e-commerce websites.
In all those projects, the businesses had to choose between using the out-of-the-box Experience Cloud solution and hosting the platform elsewhere.
I built solutions using both approaches and would like to share my experience and their pros and cons in this post.
Contents
- Salesforce Data Access
- Identity Provider
- Sharing and Visibility
- User Experience and Design
- Developer Experience and Deployment
- Licenses and Price
- Considerations
- How many native CRM features do you need to support?
- Does the master data come from Salesforce or any other systems?
- How complex and dynamic is the user experience?
- Do you already have an IdP?
- Are there any platform limitations that you need to overcome?
- How many users will you have? How often will they use the community?
- What are your available resources?
- Examples
- Conclusion
Salesforce Data Access
Since we are talking about Salesforce communities, we assume we will use the data from Salesforce as the master data.
We don't have to worry much about it if we use the Experience Cloud, as with that approach, the community integrates into the platform natively.
On the other hand, if we host the community outside the Salesforce platform, we need to set up the integration.
The most common approach is to build the server-to-server integration between the custom back-end and Salesforce org.
It would require setting up the connection application and a service to handle the access token.
Identity Provider
Another important consideration is user management.
In Salesforce Experience Cloud, you need to enable the partner and/or customer community users on the contact records, and each of those would have a corresponding user created.
It's beneficial because it gives complete visibility within the platform, and you can benefit from the platform's security via sharing and visibility.
Another benefit is that sign-up, password reset, and OTP login flows do not require much effort. It is mainly the configuration.
The communities come bundled with ready-to-use components that support minor customizations.
Note: Technically, you can still rely on the Salesforce users with the custom implementation and log in on their behalf, but it doesn't make much sense.
Following the custom implementation, you would have to implement a third-party identity provider and manage the users yourself.
For example, I've been using the AWS Cognito service. It's flexible, easy to configure and manage, and has good SDKs.
However, it will require custom implementation, but there are almost no limits on what you can do.
Sharing and Visibility
One of the biggest challenges when using a third-party IdP is sharing and visibility because you must manage it yourself.
Usually, companies connect with Salesforce via the integration user, who has access to all relevant records and services.
Depending on the complexity of the portal, you can introduce different roles, such as user and admin. Then, based on these roles, controlling what actions are available is possible.
Another consideration is record access. One of the strategies is to match the user from the custom IdP to the contact in Salesforce.
For example, in AWS, you can create the custom attribute and store the SF ContactId during user creation. The web application can access that attribute in the ID token and filter records accordingly.
Note: One of the most important things you should consider early with the custom approach is token and endpoint caching because the integration is done via the REST API, and Salesforce has a limit on calls.
User Experience and Design
The Salesforce experience cloud has many components that are out of the box, making building simple websites quick and easy. It's a low-code approach that doesn't require development resources.
Displaying the lead and case forms, knowledge articles, using a global search, and such are all available out of the box.
The default themes could be pretty slow, though.
On the other hand, if you need a highly interactive web experience and use modern JavaScript libraries such as React or NextJS, consider building a custom website.
Choosing the custom approach makes it easier to pick components from the existing design systems or libraries and follow the brand and design guidelines.
Fortunately, there are LWR sites for Experience Cloud that drastically improve community performance but limit the number of components that you can use.
Based on my experience, that might be a good way to go as a middle-ground approach because you can create quite interactive experiences using custom lightning web components.
Developer Experience and Deployment
Of course, in the case of simple websites, you might not need to develop anything, but given that you want to have a custom UI/UX and a complex and dynamic experience, you would have to implement your web components.
I primarily consider it from the front-end development point of view, and Salesforce's development experience is not the best.
I've been working extensively with frameworks like React, Angular, LWC, Stencil, etc.
The LWC, unfortunately, is not as flexible as the others, and most importantly, it is less popular.
It also limits your available development resources. Consider looking for a React vs. LWC developer. Many more React talents are available on the market.
Another point is the maintenance and community.
Many of the frameworks and libraries are better maintained than the LWC. Plus, there are a vast number of libraries for the other frameworks.
Also, if you stumble upon the issue, you'll likely find the answer in the React community.
One more issue that I want to talk about is the development process.
Salesforce has improved a lot over the past few years. SF CLI and scratch orgs are very handy, but developer experience is still far from modern JavaScript development.
The biggest issue is that there is no way to do local development with LWCs.
There were some initiatives about five years ago, but they didn't work as expected.
Last year, Salesforce announced a new way to develop components locally, but I haven't yet played around with it. The Local Dev is generally available for Lightning apps in the Spring '25 release if you want to give it a try.
With modern JavaScript frameworks, you can easily set up the local development environment and make rapid changes and deployments, which makes it an attractive choice.
Licenses and Price
Depending on the needs of the business, the Experience Cloud might be costly.
Of course, custom development would require higher upfront costs, but maintenance and savings in the cost of the licenses can make it worthwhile.
For example, I worked with a venture capital company that uses Salesforce for the master data. They had a customer portal where their customers could occasionally log in and submit investment requests and check their investments, reports, etc.
One of the problems was that they hadn't used the portal that much to justify the cost of the licenses.
Another example is a Finnish telecom company with a portal where customers can check and upgrade their current connections and view invoices. They were using the Customer Community Login licenses, but given the business margin, it was expensive for them.
Considerations
There is no clear answer on what approach to take because every business case is different and depends on many factors, which require considering several things.
I suggest assessing the following based on the business needs:
- How many native CRM features do you need to support?
- Does the master data come from Salesforce or any other systems?
- How complex and dynamic is the user experience?
- Do you already have an IdP?
- Are there any platform limitations that you need to overcome?
- How many users will you have? How often will they use the community?
- What are your available resources?
How many native CRM features do you need to support?
First, regarding the main CRM features, if you need a partner community where they can use accounts, opportunities, and contacts, there isn't much room for a custom implementation.
It's better to stick with the Experience Cloud and Partner Community licenses.
Does the master data come from Salesforce or any other systems?
Then, assess how many integrations you need and where you have your master data.
Consider a custom approach if you do not rely much on the Salesforce data and it's hard to set up required integrations natively.
How complex and dynamic is the user experience?
How complex the UI should be? Can you achieve your goals using the out-of-the-box component library?
Unfortunately, sometimes, it's hard to implement certain things using the LWCs, and, in some cases, the performance is not excellent.
Based on my experience, it's easier to implement complex and dynamic web applications with React or other similar tools. Plus, some of those have great open-source libraries that could drastically speed up development.
Do you already have an IdP?
Assess if you need to manage the users inside Salesforce or if you can rely on the existing IDP.
If you need to manage users in Salesforce, support self-registration, and use a one-time password login, then it's good to go with the out-of-the-box solution.
In some projects, companies already have their user pools managed in Azure AD (Now Microsoft Entra ID) or elsewhere, so you might not necessarily need to rely on the community users.
Are there any platform limitations that you need to overcome?
Consider how complex your required implementation is, if any Salesforce platform limitations could prevent you from achieving the goals, and if you need to implement it off-platform.
How many users will you have? How often will they use the community?
Consider the number of customer users, their user stories, and whether their portal usage will justify the license cost.
What are your available resources?
Think about your available resources, both talents and budget.
Depending on the complexity of your portal, it might make sense to reach out to Salesforce integration partners.
Finding Salesforce talents is challenging for more complex implementations if you don't have the Salesforce development team, and the integration partner teams are expensive.
With the custom approach, finding developers outside of the Salesforce domain is more effortless. However, you would still need someone to design and integrate the architecture with the platform.
Examples
Example 1: Experience Cloud
For example, I worked on the portal for the local accounting firm where customers and internal users could share the documents in Sharepoint.
It didn't require fancy UI. Customers could see the record pages and upload and download shared files. They would also use the portal regularly, and we needed to rely on the Salesforce security model for sharing and visibility.
In that example, we picked the Experience Cloud with a custom theme because we could use most of its features out of the box.
The regular usage and dependency on the security model required us to use Salesforce users. We natively integrated SharePoint as an external data source and configured a programmatic sharing automation to support complex business cases.
Example 2: Custom Implementation
Another example was the customer portal for a manufacturing company.
They needed a portal where office managers could manage their phone booth fleet across different locations, check the live analytics, and configure the calendar integrations.
The UI in that example was very complex as the goal was to have the web application with a shared state between the pages, heavy integrations with IoT devices, Google Maps, and Google and Microsoft Calendars.
The customers should've been able to use advanced features such as setting up the location hierarchy, assigning devices to those locations, and rendering them on the map.
We didn't require the Salesforce CRM features. Most of the master data came from the other systems. We just relied on a few standard objects in Salesforce.
Eventually, we selected the custom implementation integrated with Salesforce, allowing us to deliver results quickly as part of the R&D project.
Conclusion
As you can see, for every use case, there are plenty of things to consider when deciding which approach to take in building the Salesforce communities.
Almost always, going with the Experience Cloud is a safer bet because it allows you to take the maximum of the platform features and rely on its security model.
But, it might not be that straightforward for more complex implementations to make a decision, and some companies might want to consider implementing a custom solution for one thing or another.
That's why I wrote this article highlighting the areas to review within your business.
I suggest going through the points and discussing them with the team. Then, create quick prototypes and review them with the stakeholders.
I hope this post will help you to make a decision that fits your business the best.
P.S.: If you have any questions, want to share your experience, or want to chat about the topic, drop me a line or connect with me on LinkedIn.
Nikita Verkhoshintcev
Senior Salesforce Consultant
I'm a senior Salesforce consultant based in Helsinki, Finland, specializing in Experience Cloud, Product Development (PDO), and custom integrations. I've worked as an independent consultant building custom Salesforce communities and applications since 2016. Usually, customers reach out to me because of my expertise, flexibility, and ability to work closely with the team. I'm always open to collaboration, so feel free to reach out!