This phase of the Salesforce Platform Governance Method focuses on your projects’ use of communities within the Salesforce platform.
Overview
Customer
Partner
Employee
These three community types cover the main user groups that you would expect to interact with your business in one way or another. For clarity, customer communities are those users that are buying services or products from your company and looking for support or help; these could be businesses (B2B) or consumers (B2C). Partner communities are those users that collaborate with your business to sell and support services or products. Employee communities are the people that work for you and may require access to information via a portal.
Essentially, the Salesforce platform is an SaaS (Software as a Service) solution that is delivered to the end user via a browser. You could argue that the community within the Salesforce platform is just another view delivered by that SaaS solution.
The Salesforce Platform Governance Method: Phase G
“A constantly changing group of people collaborating and sharing their ideas over an electronic network (e.g., the Internet). Communities optimize their collective power by affiliation around a common interest, by the compression of the time between member interactions (i.e., communicating in real time), and by asynchronous ‘postings’ that potentially reach more participants and permit more reflection time than real-time interactions.”
—Gartner1
If your project is delivering a community solution as part of the overall application, your governance team will need to be assured that the project has put the correct measures in place to control the visibility of data. Additionally, a community that is externally focused, such as a customer or partner community, has some responsibility for delivering your brand image. A bad experience using your customer community could cause brand damage and lose your business customers. Equally, upsetting partners could create long-lasting damage for your business as well as your partners’ businesses.
Internally focused communities have a responsibility to deliver a great experience for your employees, as frustrating your employees with a badly delivered and poorly thought out community could cause your employees to look elsewhere for a job.
Although your governance team is unlikely to have input into the structure or functionality of the Salesforce community, they should be aware of branding guidelines and of course take a keen interest in any quality aspects of the project’s community. Your governance team will be protecting your company’s public image to some extent.
Design
Phase G: communities - design
Govern the license types associated with the sites and communities
Depending on the target audience for your community, there are a number of different license types available. Your governance team should be looking for assurance that the project has selected the correct license for their particular use case, and that they have considered the quantity of licenses required.
Customer Community – Allow your customers (B2B and B2C) to engage with both your company and other customers via an online portal.
Partner Community – Provide your resellers, distributors, and brokers limited access to the Salesforce platform to pass you leads and work on sales projects with your sales team.
Employee Community – Provide employees limited access to your data within the Salesforce platform. Use this license type to build custom applications for your employees when they do not require a full Salesforce license.
Salesforce Community License Types
Community | License | Description |
|---|---|---|
Customer | Customer Community | This license type is generally associated with a B2C use case, with a large number of external users. |
Customer Community Plus | This license type is generally associated with a B2B use case, typically for non-sales support requirements. Additionally, this license is appropriate if a customer requires access to records that are not linked to their own account or needs to view dashboards and reports or have delegated administration rights. | |
Partner | Partner Community | This is similar to customer community but also offers your users access to data that relates to your sales processes, typically leads, opportunities, quotes, and campaigns, among others. |
Employee | Lightning Platform Starter | Similar to customer community but offering your users access to some standard objects, such as accounts, contacts, cases, and activities. Objects relating to the sales process are not available. Additionally, cases are limited to internal and employee cases and not those raised by customers. This license provides access to 10 custom objects, so may be limiting depending on the complexity of your project’s application. Also, the number of API calls per day per community member is 200 regardless of Salesforce platform edition. |
Lightning Platform Plus | Builds from Lightning starter but provides access to more customer objects, with the limit of customer objects being raised to 110, which allows for a much more rich and complex application or number of applications. Additionally, there are some API call limits raised with this license type with Enterprise Salesforce platform editions having 1,000 API calls per day per community member and 5,000 API calls per day per community member for Unlimited editions of the Salesforce platform. |
Your governance team will need to look at the longer-term requirements of your project and question whether the correct license type has been used given the roadmap for the project’s application.
If your project is delivering a new application for your employees to access via an employee community, and that application is on the verge of consuming 10 custom objects, your governance team may see this as a potential future problem.
In general, upgrading licenses is not a problem; however, it is not usually possible to downgrade licenses.
Your governance team will also want to review the license consumption holistically, as multiple projects may be delivering communities, which will not be looking at the overall license position for your company. Pooling licenses may provide a better commercial position when discussing license requirements with Salesforce.
Govern the sharing usage for partner, customer, and employee community users
There are many ways to provide data access and visibility of objects and records to your community users.
The Salesforce platform provides various layers that will determine access, beginning with the baseline access (external organization-wide defaults) controlled by profiles and permission sets. The Salesforce platform then provides many out-of-the-box capabilities to share records with external users based on their license type. Your project should document their sharing requirements and review what is possible with sharing to help them plan better and provide your governance team with the assurance they need.
The project has planned their sharing model.
The project has defined their sharing requirements.
The project has determined the sharing options they should use.
The project has updated their sharing requirements with the sharing option they will implement.
The project team has planned its sharing model
Community Sharing
Area | Description |
|---|---|
External Organization-Wide Defaults | Baseline access similar to internal org-wide default to set a different default access level for external users. When you first enable external organization-wide defaults, the default internal access and default external access are set to the original default access level. As of the Spring 2020 release, the external org-wide defaults are enabled by default in all new orgs to better secure your data. If you have an existing org and you plan to share records with external users, then you must enable the external org-wide defaults. |
Role Hierarchy: Customer Community Plus and Partner Community, Channel Account, and External Apps licenses | These are role-based licenses, which means access to records rolls up the hierarchy. The role hierarchy automatically grants record access to users above the record owner in the hierarchy. You can control sharing access using hierarchies for any custom object, but not standard objects. |
Sharing Rules | Use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rules give particular users greater access by making automatic exceptions to your org-wide sharing settings. |
Sharing Sets | Sharing sets let you take a lookup, such as account, contact, or user from the community user, and match it to records in your Salesforce org that also have that lookup value. |
Manual Sharing | Sometimes it’s impossible to define a consistent group of users who need access to a particular set of records. In those situations, record owners can use manual sharing to give read and edit permissions to users who don’t have access any other way. |
The project team has defined its sharing requirements
Your governance team will need to see evidence that the project team has clearly defined its sharing requirements. It is not possible to determine the best approach to sharing data with external users without first defining and documenting these requirements.
Project sharing requirements
The template in Figure 8-3 provides an example of a project sharing requirement document, which captures the following:
The business requirement for external sharing
The community license type that will be used
The object being shared
The owner of the record
The user or group the object is being shared with
The sharing option that has been selected as most appropriate to meet the business requirement
If multiple projects are creating communities, your governance team may need to centralize the overall sharing requirements so that it is easy to understand the holistic sharing solution. The template could be extended to add the project team to provide this.
A simple Salesforce platform application could be constructed to deliver this template to be completed online by the project team, which could feed directly into a company-wide view of your sharing model and provide easier reporting. Additionally, this could also highlight any pre-existing sharing configurations.
The project team has determined the sharing options it should use
Once your project has defined and documented its business and sharing requirements, the project team can review the available options based on the license type.
Sharing Options
Sharing Option | Customer Community | Customer Community Plus | Partner Community | External Application |
|---|---|---|---|---|
Sharing Sets | Yes | -- | -- | Yes |
Share Group | Yes | -- | -- | -- |
Folders (Reports and Libraries) | -- | Yes | Yes | Yes |
Sharing Rules | -- | Yes | Yes | Yes |
Manual Sharing | -- | Yes | Yes | Yes |
Partner Role Hierarchy | -- | Yes | Yes | Yes |
External Account Hierarchies | -- | Yes | Yes | Yes |
External Delegated Admin | -- | Yes | Yes | Yes |
Super User | -- | Yes | Yes | Yes |
Account Relationships (Account Relationship Data Sharing Rules) | -- | Yes | Yes | Yes |
Account and Opportunity Teams | -- | Yes | Yes | Yes |
Apex Managed Sharing | -- | Yes | Yes | Yes |
- 1.
Select the community license type and update the object access. Each license type comes with baseline access or entitlements. By design, the out-of-the-box object permissions of user profiles associated with community licenses are rather restricted. Document the object.
- 2.
Review the external organization-wide defaults—baseline access similar to “Internal Org Wide-Default”—to set a different default access level for external users. When your project team first enables external organization-wide defaults, the default internal access and default external access are set to the original default access level, which is Private.
- 3.
Does the account role hierarchy provide the record access? Customer community plus, partner community, and external apps licenses are role based, which means access to records rolls up the hierarchy. When your project team enables the first external user on a partner account, a user role hierarchy is created for that account. This role hierarchy rolls up to the account owner. The three partner user roles in this hierarchy are partner user, partner manager, or partner executive. When your project team creates contacts on the partner account and converts them to external users, assign one of these roles to them.
- 4.
Extend access with sharing sets. A sharing set grants community or portal users access to any record associated with an account or contact that matches the user’s account or contact.
- 5.
Use sharing groups to share records owned by high-volume community users. Sharing groups allow you to share records owned by high-volume community and portal users with internal and external users. Sharing groups apply across communities or portals and are associated with sharing sets.
- 6.
Enable account and opportunity teams. An account team is a team of users who work together on an account. Set level of access for account, opportunity, and case objects. Set up a default opportunity team of coworkers you typically work with on opportunities, with a role for each member and special access to your opportunities. Set up a default account team and a default opportunity team.
- 7.
Use declarative sharing rules to extend access to users in public groups, roles, or territories. Sharing rules give particular users greater access by making automatic exceptions to org-wide sharing settings.
- 8.
Grant access with account relationships or point-to-point relationships with granular data access. Grant record access to partner or customer accounts and protect confidential data by sharing only select information. Channel account managers can use account relationships and account relationship data sharing rules to target how information is shared and who it’s shared with.
- 9.
Set up external account hierarchies, which work like Salesforce role hierarchies. Account records belonging to child accounts in an external account hierarchy share data with the parent accounts in that hierarchy. As a result, data can be shared without creating sharing rules.
- 10.
Don’t forget about built-in sharing behavior (a.k.a. implicit sharing). There are a number of sharing behaviors that are built into Salesforce applications. This kind of sharing is called implicit because it is not configured by administrators; it is defined and maintained by the system to support collaboration among members of sales teams, customer service representatives, and clients or customers.
Your governance team may want to review this matrix to be assured that the project team undertook a comprehensive review to determine the appropriate sharing option to use for each business requirement.
The project team has updated its sharing requirements with the sharing option it will implement
Project Sharing Requirements Updated
|
As previously mentioned, your governance team should implement a companywide sharing requirements document (or application) if you have multiple projects.
Govern the different UI / UX capabilities to style a community
Your governance team has a long-term view of all projects being delivered. They understand that the applications built for their company may be in use for years after the project team has moved on to new projects or even different companies. With this in mind, your governance team will want to understand any areas where the project team has made changes that might expose the company to future challenges as the Salesforce platform is enhanced over the years.
Salesforce makes three releases of its core platform every year. With those releases are packages with thousands of enhancements and completely new capabilities. Additionally, over time we can expect UI / UX updates, just as the original UI (now known as Classic) changed into Lightning, and also how Lightning changed from the Aura-based technology to the Lightning Web Components technology.
Given the relentless pace of change and the ever evolving user interface that people expect, and the fact that technology will no doubt be delivering new devices that will run the platform, your governance team needs to make sure that your company can consume all these future Salesforce features without challenge or disruption.
When Salesforce introduced Lightning, the migration from Classic to this new interface was a big problem for some companies. Those that heavily modified their applications and moved beyond the safe boundaries that Salesforce has in place suffered greatly. There are companies still struggling today to move away from the Classic user interface because of this. Your company does not want to be in this position in the future.
Although Salesforce categorizes its community extension as customer, employee, or partner, many companies have gone beyond that out-of-the-box experience to deliver something truly bespoke. However, your governance team should look out for any project that has put a lot of effort into changing their community way beyond the standard framework that Salesforce delivered.
For example, overriding CSS is not recommended. The best way to update any styling requirements for your components is to use the Theme panel in Experience Builder.
Use the CSS Editor in Experience Builder to add custom CSS that overrides the default template and theme panel styles. You can also use it to make minor changes to the appearance of out-of-the-box components, such as padding adjustments.
Use custom CSS sparingly. Future releases of template components might not support your CSS customizations. Additionally, Salesforce customer support cannot help resolve any issues with custom CSS.
If your project has had to make a lot of customizations for styling, you are likely to see an issue in the future when updates to the template you have used are made by Salesforce. This could leave your community stuck on a template or template version and require major investment from your company to move away from your customized template into a supported template.
Your project team should assure your governance team that any styling changes have been absolutely necessary, and document them clearly so that future teams and support personnel can troubleshoot problems if they arise.
Govern the mobile considerations for communities
The reduction of page load times
The usability of the page given the different screen form factors
It is unlikely that your project will be able to test for every device and screen factor, but some effort should be made to make sure the user experience is largely a good one.
Your governance team should be assured that the project team has made sure images are optimized for mobile devices (which should be enabled by default) as well as hid non-business critical components.
Identity Management
Phase G: communities - identity management
Govern how identity management is handled within communities: provisioning, syncing, and de-provisioning
Your project team has several options for authenticating customers and employees in your community site. Customers are users with community, customer portal, external identity, or partner portal licenses. By default, they can log in with the username and password that Salesforce assigns them for the Experience Cloud site.
Your Salesforce org’s employees are users with full Salesforce licensing capabilities. These users follow the employee login flow using their Salesforce username and password.
Beyond these default settings, your project team can configure SAML, third-party authentication providers, or OAuth to authenticate and authorize all users accessing your site. Your project team can also configure self-registration or Just-in-Time (JIT) to use Login Discovery, which makes it easier for users to authenticate.
Your governance team may look for assurance around license consumption for self-registering users onto the community.
For consumer community sites, your governance team will want to review the process for provisioning and de-provisioning users. Not all identity solutions, if your project is using an external identity provider, support de-provisioning of users. Additional functionality may need to be delivered by your project team to overcome this.
Govern the use of external identity (Facebook, Google, etc.) if appropriate
Employees and customers can access a community site through a third-party authentication provider. For example, if your project configures Facebook as a third-party authentication provider, your users can log in to Facebook through a link on the community site login page. Facebook authenticates the user, allowing them access to the site.
Salesforce provides a simple way to set up several common authentication providers, such as Facebook, GitHub, Google, LinkedIn, Salesforce, and Twitter, instead of creating your own app on the third-party site.
Your company may have security policies in place that provide your project teams with guidance on acceptable external identity providers. Your governance team will want to be assured that the project team adhered to this policy.
If no such policy exists, your governance team may review the community in terms of data exposed and functionality available before deciding whether a particular external identity is acceptable. However, for most consumer use cases, it is common that social media providers are acceptable providers, and your project team will want to make authentication as straightforward as possible for their main customer base.
Method
This is the formal method for Phase G of the Salesforce Platform Governance Method. The objectives of Phase G are to ensure that your project teams have used the Salesforce platform’s community capabilities properly and are not inadvertently exposing any data to the wrong people.
There is an element of taking a least-privilege view when it comes to data visibility, but that requires that your project teams have determined the business requirements for driving data sharing and visibility.
Design
Identity Management
Approach
This phase requires that your project team supplies a number of artifacts for the governance team to review. Your governance team will be looking to approve your project team’s solution as quickly as possible, without necessarily knowing all the details of your community. With this in mind, governing the use of community could take the approach of an initial review where your project team presents the overall community approach and outlines the basic business requirements. With that review over, your project team could then dive into the details of the business requirements and complete the templates, delivering the artifacts to your governance team for a second review.
Inputs
Project sharing requirements
Project completed Salesforce external user sharing resource matrix
Project sharing requirement options
Project bespoke styling requirements
Steps
The steps to govern your project team’s community site will help the team to deliver a quality solution that can confidently support your customers for the foreseeable future without damaging your brand, or a partner community site that helps all parties be successful in their business. Your employee community site will be somewhere your employees will find what they need to help them in their jobs.
Whichever community your project is building, it will have to withstand three substantial platform releases each year. Ultimately, your business will want to have these updates applied without causing any issues with your community sites.
Design
- 1.
Govern the license types associated with the sites and communities
- 2.
Govern the sharing usage for partner, customer, and employee community users
- 3.
Govern the different UI / UX capabilities to style a community
- 4.
Govern the mobile considerations for communities
Identity Management
- 1.
Govern how identity management is handled within communities: provisioning, syncing, and de-provisioning
- 2.
Govern the use of external identity (Facebook, Google etc.) if appropriate
Outputs
Not Applicable – This phase in the Salesforce Platform Governance Method is not applicable to the project.
Remediate – The governance team requests that the project team remediate its design to accommodate the issues raised during the governance review.
Pass – The governance team has found no issues or concerns with the project’s proposal and therefore the project has passed this governance phase.
Review – The governance team has found the inputs cannot be objectively measured and therefore a subjective view has been made, which will lead to a discussion with the project team to reach consensus. Although undesirable, this could be a consequence of unclear standards/policies.
Scenario
Govern the different UI / UX capabilities to style a community
Hanna Snyder, the project architect from our company Bright Sound Guitars, has brought a proposal to the governance team regarding the use of a community site for their customers. The business wants to provide a support portal for their guitars, where customers can seek technical advice and raise cases when things not going well with the guitars they have purchased.
On the surface, the governance team cannot find any issues with Hanna’s suggestion and on first review gives Hanna the all clear that she is onto a great solution and everything makes sense. Hanna goes back to her project team and starts her detailed requirements capture and design of the community portal.
On returning to the governance team a few months later, Hanna has brought with her Ranveer Shah, her Salesforce developer, and Darren Perry, her business analyst. Darren does a great job of presenting the community portal and all the functionality that they intend to deliver to the customers.
Things are going great during the governance review until Darren presents the community wireframes and UI mock-ups. Darren has really taken customization of the community to a new level.
Ranveer explains the lengths to which he has gone in order to tailor the community user interface and experience to meet Darren’s requirements. Ranveer has CSS being overridden throughout, tailoring the look of the community beyond recognition from the original Salesforce template. He also used high-definition images throughout, as they felt these gave the best view of the guitars, especially those with the high-gloss finish.
The governance team raises a major concern with the amount of customization that Ranveer has done. This level of customization would leave Bright Sound Guitars exposed when Salesforce updates the template or changes any of the CSS classes they have used within the template. This could leave Bright Sound Guitars stuck in the past in terms of the template, not being able to upgrade without a major investment from the project team to remediate any issues.
Hanna steps in and agrees. She raised the issue early on that the levels of customization were too high and did not significantly improve the usability of the community portal; however, Darren did not agree.
Using a mock-up of the community, the governance team tests the site from their mobile phones. The load times are atrocious and unlikely to win any favors from their community of customers.
Darren admits that this might drive away users rather than encourage the community spirit for which he was hoping. Hanna suggests that the team go back to review the amount of customization to see how a compromise can be reached.
Summary
Creating a community for your customers is a big responsibility. In some respects, it should be no different than doing so for your employees, but the main difference is that your employees could accept issues, or some level of “clunkiness,” that your customer just will not.
Phase G tackles the governance of your community requirements, focusing on maintainability and data sharing and visibility. Once a community is out in the public, it is much harder to manage failures and could create brand damage for your company.
During this phase you have highlighted to your project teams the areas of concern and provided feedback as to what needs to be done to bring the community project to an acceptable level to pass governance.