Community Cloud is now Experience Cloud.
Used to build multiple customer touchpoints through digital experiences.
->Customer Service
->Partner Management
->External apps
Digital Experience :
If you are working with a new org that has not yet created a community, then you will have to enable digital experiences before you can start creating any sites.
Note :
New orgs will enable digital experiences.
-> Select a unique domain.
External sharing model different than internal model.
User Access Considerations :
which users need access ?
-> Internal users
-> Partners
-> Customers
-> Guest users
External users or customers will only have access to the customer site,
and external users known as partners will only have access to the partner site.
External Login-based Licenses
1.External Apps
2.Customer Community
3.Customer Community Plus
4.Partner Community/Channel Account
External Apps License :
For the External Apps licenses, it was designed for light B2C or business-to-consumer usage scenarios.
It is typically seen as a sort of commerce portal.
Most importantly, it offers minimal access to Salesforce data and allows access to just a few standard objects.
2.Customer Community License
The Customer Community license is also used for business-to-consumer solutions, but it offers access to more Salesforce objects
than the External Apps license does. These objects include data like cases and events, along with data related to customer service
such as the work order and service appointment.
3.Customer Community Plus License
For customer-based sites that focus around driving sales, the Customer Community Plus license is available. This license offers the same sharing benefits as the full internal license does.
4.Partner Community License
Good for B2B scenarios where you need access to leads,opportunities and campaigns.
Channel Account :
Salesforce offers a similar license known as the Channel Account license.
In terms of features and access, it is essentially the same as the Partner Community one.
It is just packaged a little differently.
This one is perfect for companies with sites that need to calculate usage based on the number of partners and not individual use.
Guest User Profile :
Special kind of profile access for unaunthenticated users.
Each site is assigned a guest user for unauthenticated access.
"secure guest user record access' setting :
Having this enabled means that org-wide defaults for guest users will always be private for all objects, regardless of what external org-wide settings
have been enabled for this org. And this is a good thing since it helps tighten security for any public-facing sites that can be accessed by
unauthenticated users. This means that in order for guest users to have access to data they need, they will need to
specifically create sharing rules for these guest users.
Customer Community Login vs Customer Community :
The "Customer Community Login" licenses are for logins-per-month pricing, and the "Customer Community" licenses are for named-user licensing.
High Volume Customer Portal license :
These are intended for sites with thousands or millions of users, but they are limited in what access they provide.
External Sharing Options :
1.Sharing Sets
2.Share Groups
3.Account Role Hierarchy
4.External Role Hierarchy
5.Account Relationships
6.Super Users
When it comes to associating these options with specific licenses, sharing sets and share groups are available to users
with the Customer Community license since this license is not role-based.
keep in mind that the default level set for external access cannot be more permissive than the access for internal users.
Sharing Sets and Share Groups :
Sharing Sets:
Grants access to records associated with :
->Account or contact records that match the user's account or contact.
-> works with access mappings
Use Profiles and not roles to grant access.
Sharing sets work by granting access to records via something known as an access mapping.
Access Mappings :
Assume that there is a need to grant external users access to the case object.
When setting up a sharing set, you will need to specify whether the ID associated with an account matches the related account ID for that case
or whether this match comes from the ID associated with the contact. You will then need to specify what access level should be allowed,
and this can be either public read-only or public read/write.
Share Groups:
Share groups work together with sharing sets to grant access to internal users for any records owned by external users that are part of the sharing set.
But there can only be one share group associated with a sharing set.
Account Role Hierarchies :
Account role hierarchies to facilitate sharing with external users.
Default partner roles :
The first is a partner user, followed by a partner manager, and partner executive.
Whenever the first external user is enabled for a partner account, an account role hierarchy is created.
If the number of roles for the site remains at three, then this will include a partner user at the bottom of the hierarchy,
and above that will be the partner manager and partner executive at the very top.
Account Relationships:
Used to connect two partner accounts.
Configured with clicks and not code.
Configure data to be shared through rules.
To take advantage of this feature, it will first need to be enabled in the org, and once it is, it cannot be disabled.
External Account Hierarchies :
External account hierarchies is a feature that was introduced as a beta feature in the Summer '20 release and has now since moved to general availability.
It works very similar to the role hierarchy that is used for internal users since it opens up access vertically to users with higher roles.
It is just that this feature is used for external users assigned a role-based license, and here is the thing that separates it from account relationships.
It does not require setting up sharing rules.
Note :
Just like account relationships, this is a feature not enabled by default. But once it is turned on in an org, it cannot be disabled.
If it is enabled, a new external account hierarchy object will be created.
Note :
Use of the more advanced sharing features may come with the advantage of wider access for external users, but there are always tradeoffs to consider for that wider access.
Super Users :
Super users are what was once known as portal super users.
Super users allow site users to view the records of other users that are either at the same level or below them in the hierarchy.
This feature is available to users assigned the Customer Community Plus or Partner Community licenses only.
it must first be enabled by toggling it on in digital settings.
As long as super user access has been enabled in the org and each of these partner managers has been enabled as a partner super user,
they should have access to each other's records.
This feature is limited to certain objects such as opportunities, leads, cases, and custom objects.
Summary :
1.Which external user sharing feature available is dependent on license-either role based or non-role based.
2.External User sharing features :
->Sharing sets and share groups
These two features are only available with the customer community license, which is non role-based.
This means the feature must work with a profile to open up access.
It also means they can perform well for simple sites with thousands or millions of users.
These are known as high-volume sites.
-> Account role hierarchy
Beyond this are the advanced sharing features which are role-based. It begins with the account role hierarchy.
-> Account Relationships and sharing rules
If a more granular level of access is needed, there are account relationships, which work together with sharing rules.
-> External Role Hierarchy
For sites that do not want to work with sharing rules, there is a new feature known as the external role hierarchy.
->Super Users
They will be able to share records with users that are at the same level or below them in the hierarchy.
Note :
1.A site user's access begins with the user's baseline record access along with the external org-wide defaults set for the org.
2.These external org-wide defaults can never be more permissive than the equivalent internal setting,
which is logical since you would never want an external user to have more access than an internal one.
3.It is considered a best practice to limit the number of customer and partner account roles allowed in an org.
4.it is important to remember that by using features that allow more granular sharing, well, this results in a trade off where there will also be more limits along with possible site performance problems.
Guest User Profile :
Restricted access for unaunthenticated users.
-> Greatly enhanced in summer 20, etc
-> Use sharing rules to grant access.
-> Guest users cannot own new records.
Records should be assigned to default owner.
Sharing Sets :
-> Grants access to records that match the user's account or contact record.
-> Use profiles and not roles to grant access.
-> Only one sharing set per object and profile.
No comments:
Post a Comment