With tens (or even thousands) of users in your Salesforce organization, choosing the right way to make data visible is an administrator priority: you have to control who sees what and you need to be aware of all the options your Salesforce customer relationship management (CRM) provides.

It's not a coincidence that secure data access is the first subject we are going to study in this book.

In my 10 years' experience, being able to master data access management has always been the key to better data organization, better platform performances, better CRM usability, and of course better customer satisfaction.

Profiles define how users can access data and the whole Salesforce application.

Your organization comes with standard profiles that (there are exceptions for some Salesforce editions, such as contact manager, group edition, or essentials edition), you can customize a few permissions for on a standard profile or clone (creating a new custom profile) so that you have full access to its customization (for example, custom object access, field-level security access). The only thing you cannot change is the license type related to a profile.

Permission sets are similar to profiles with a simple difference: you can assign zero or more permission sets to a single user, thus providing additional...

Once you have selected which objects and fields a user can have CRUD access too, you need to know how to control record-level access. We can do this using Salesforce's sharing settings.

To define the Organization-Wide Defaults sharing settings, go to Setup | Security | Sharing Settings:

A selection of standard objects and all custom objects can be set in this page.

By default, Salesforce uses role hierarchies to grant access to records to the users that belong to roles above a given user...

The last way to share records is by aligning your company's sales territories hierarchy. This kind of sharing model is applied to account sharing and related opportunities.

At the time of writing, there are currently two different kinds of territory management:

• Original territory management
• Enterprise territory management

For the scope of the Salesforce Advanced Administrator certification, we'll describe the latter since original territory management will be retired in June 2020 (this announcement can be found at https://help.salesforce.com/articleView?id=000273181&language=en_US&type=1).

Before closing this chapter, a few words should be said on how sharing is handled in communities. You should already be aware of what Salesforce communities are, but let's provide a brief summary anyway.

Salesforce communities are a way to allow external people to interact and collaborate with your business processes. This includes customers, partners, or even employees. They are an effective way to share Salesforce data with external users and allow internal users to interact with them, reducing the service cost.

Communities are created using point and click features with tools such as the Community Builder with built-in Lightning components ready for admins to use. You can even create your own customizations using Visualforce pages or Lightning components (with your developer's help):

An organization can have...

Record-level security is one of the most important topics when designing a successful Salesforce implementation. By completing this chapter, we have learned about the power of the Salesforce sharing model and all its possible options, from permissions to org-wide defaults, mastering sharing rules and role hierarchies, segmenting your accounts with Enterprise Territory Management, and controlling how Salesforce communities play a role in oversharing.

The Salesforce platform runs in a multi-tenant architecture, which means our Salesforce organization runs on the same server as other Salesforce organizations, which in turn means that we are all using the same resources. To keep your customization clean and performant, we need to know exactly which resources are used the most so that we don't reach our organization's limits.

In the next chapter, we will cover organization...

1. You want to hide the shipping address fields of the account object from all of your sales representative users. What do you do?
   1. Configure field-level security to hide fields from sales representative profiles.
   2. Create a permission set to configure field-level security to hide fields.
   3. Assign no layout to the account object.
   4. Change the org-wide default sharing to Controlled by Parent for the Shipping Address object.
2. You need the sales representative users to be able to do some service-related work. What do you do?
   1. Create multiple profiles and assign them to the sales representative users.
   2. Assign a sales representative profile and the service representative profile to the selected sales representative users.
   3. Use a permission set to enable specific service abilities.
   4. Create a new license and profile to provide the new service features.
3. You want to give Delete access...