Running a Public Community? 6 Secrets About Using Salesforce Experience Cloud0
I recently worked on a project to transition our community platform from Discourse to Salesforce Experience Cloud. Discourse is a highly customizable, open-source community forum that caters to various needs. However, it can pose several challenges in an enterprise environment.
These challenges include managing member personas, Single Sign-On (SSO), role-based navigation for customers and partners, federated search, reporting, and case deflection, among others. Therefore, we needed a platform that not only served our community strategy but also aligned with our business architecture.
Enter Salesforce Experience Cloud. This platform supports all the aforementioned features and is highly customizable, allowing for a nearly limitless number of integrations. However, there are several factors to consider before choosing it as your community platform. Here are six insights I wish we had known before starting the transition.
1. The Hidden Cost Dilemma
We found out that we already had Experience Cloud licenses when we started looking into SFDC, which was great because it meant no extra costs. But understanding how the licenses worked was a bit tricky. There are two types – login and user licenses, and they have different prices.
We used the login license for our public community, which means members get a certain number of logins each month but get logged out daily. This was different from our previous system, where members stayed logged in and some people didn’t like the change.
We also used SSO integration with our external identity instance for customers, partners, and public accounts. But this could get expensive when we grow to 180k members. This is because our aim is to be a public community that anyone can join. If we were a traditional SFDC customer community, this might not have been a problem. We could have used the standard Out-of-box authentication instead.
On top of licensing, there are also development costs. We had to move our community from Discourse, a platform that’s great for rich media and markdown, to SFDC, which is a bit less flexible. We hired a 3rd party vendor to help with this and found out that there will be a lot of development work needed to get SFDC experience cloud to support a public community properly.
In summary, SFDC may appear more affordable if you’re already using the platform. However, hidden costs can arise with development if you need to use the platform for anything beyond a traditional customer community use case.
2. Customization Complexity
Being that we were using Experience Cloud for a public community, it meant we had a lot of customizations that we had to flush out. Not only that, but we also had to consider permissions for various pieces of content. Since we had Guests, Customers, Partners and Employees all using the platform, we needed to ensure that content was only accessible by the correct members.
For example, we needed the ability to nest “sub-forums” within categories. This was a significant architectural change from traditional forum software. SFDC uses Groups and Topics, and establishing a relationship between them requires custom development. Consequently, we needed community members to create content within any group or topic from the homepage. This necessitated a custom “start a conversation” widget, complicating the standard rich text editor.
One lesson I quickly learned with SFDC customization is how easy it is to lose parity through customization. When you create something custom, you start from scratch, and out-of-box functionality is lost unless you specifically include it in the scope of work. This results in a lengthy list of development requirements to add functionality to an out-of-box feature, creating “scope creep”. Use out-of-box solutions whenever possible and understand the difficulties of customization.
Use out-of-box solutions whenever possible and understand the difficulties of customization.
Ongoing customizations also require effort either from a third-party vendor or an internal business development team. We were lucky to have an excellent in-house development team. They quickly handled all necessary improvements through their Agile efforts. This team, true rockstars, delivered everything that was requested. However, we had to balance their work within the available resources and sprint allotments.
3. Learning Curve Labyrinth
Before this project, my knowledge of Salesforce was quite limited. I had used it in previous roles as an Implementation Engineer, but primarily for managing contact records and help articles. Understanding the Experience Cloud platform was challenging due to its steep learning curve. In hindsight, I would have allocated more time for training. Learning to use the builder, workspaces, moderation, dashboards, and reporting was difficult. I spent considerable time on emails and Slack messages trying to understand these new elements. However, I was able to grasp things fairly quickly. It takes time and patience, but once you understand the platform’s operation, it becomes quite intuitive, especially regarding usability.
Having a knowledgeable resource on the team is crucial for any community effort, especially a public one. This resource can guide you through Salesforce and provide advice on proper architecture and implementation from the start. I remember having lengthy conversations about content types and finding the right fit within Salesforce to accommodate them. The Experience Cloud uses Chatter by default, which is only one type of content that can exist on a public community. Chatter does have some limitations, more on that later.
In summary, it’s important to have someone on the team who understands Salesforce and is dedicated to the community effort for its success. Additionally, ensuring that all team members understand the platform will set you up for success in the long run.
4. Integration Considerations
Integration with Salesforce (SFDC) is straightforward when used traditionally. If SFDC is your record for customers and contacts, then the Experience Cloud is a great complement. However, integrations require some development effort. For example, we wanted a Slack integration to notify our team when new messages were posted in specific community areas. To achieve this, we had to customize the standard Salesforce > Slack application.
All integrations must go through your development process. While this ensures proper quality assurance (QA) and security measures, it can slow down integration timelines as they must fit in with other development efforts. Prioritization becomes your new currency.
All integrations must go through your development process.
Unlike other platforms that often have ready-made solutions to plug into your instance, any SFDC integration must be properly scoped, discovered, developed, QA’d, and pass User Acceptance Testing (UAT) requirements before being implemented in production. It’s important to properly plan and understand your integration path. However, remember that prioritization is your currency, so spend it wisely.
5. Limited Functionality
Experience Cloud is an excellent platform for building a customer community. It allows customers to ask questions, engage with support, and drive a case deflection strategy.
However, it has some limitations. For an open and public community requiring diverse content types, such as questions, answers, blogs, videos, and how-to articles, Experience Cloud might not suffice. Its primary mode of discussion is through Chatter, which only supports questions and answers and is limited to 10,000 characters. This can pose a challenge for our technical community that often needs to share long-form content like tutorials and how-to guides that exceed this limit. Customizing the conversation workflow within SFDC can also be a project in itself.
Moreover, the platform defaults to using SFDC Files for rich media such as images and videos. However, there are limitations on file size and type, which can be problematic for larger video files or images, making media sharing complicated.
If your requirements include rich media and the ability for users to copy and paste content with images into your editor, a custom approach is necessary. The customization path often comes with new challenges.
6. User Adoption Uncertainties
Transitioning user adoption from an open-source platform like Discourse to SFDC posed a unique challenge. Initially, all users needed to log into the new platform, agree to our new Terms of Service, and ideally, start posting. However, we found that users are generally resistant to change.
The registration process for a public community can be complex. It involves addressing spam, gathering certain pieces of information, and ensuring members can log into all their digital resources with an external identity.
SFDC’s out-of-the-box search functionality is subpar, creating adoption obstacles. Technical users often depend on search to find necessary information. Without a powerful search feature, which is also a technical limitation, users may be reluctant to join the community.
Ultimately, users need to know how to post questions, find answers, and continue with their day. If there are too many barriers to these tasks, they may abandon their attempts and post on Reddit or create a support case instead, undermining the purpose of a “Tier-0” technical community.
I may have inadvertently portrayed Salesforce Experience Cloud as an inadequate platform, which is not the case. Communities like the Trailhead Community show that a public community is feasible, albeit with considerable customizations.
For an organization already using SFDC and aiming to create a customer community for peer-to-peer interactions and case deflection, Salesforce Experience Cloud could be an ideal solution. However, for a public community, the platform, though functional, might require significant adjustments, which isn’t always ideal. The adage, “just because you can, doesn’t mean you should,” aptly applies to SFDC customizations.
A well-defined community platform strategy can guide you through Salesforce’s complexities. It can help you identify areas that require customization and areas where out-of-the-box functionality suffices. While platform decisions might not always be under your control, maintaining flexibility and outlining steps to achieve your community goals is crucial.