Salesforce Certified Platform Administrator II - Part 1

In this lesson, I provide a high-level overview of the Salesforce Security Model. 

Data access in Salesforce begins with the User. Levels of access vary based on the type of user that is logging in. It is important that you understand the different license types available in Salesforce.

You can view your organization’s licenses in Company Information via Setup.

Profiles and permission sets provide object-level security by determining what types of data users see and whether they can edit, create, or delete records. For each object, the “View All” and “Modify All” permissions ignore sharing rules and settings, allowing administrators to quickly grant access to records associated with a given object across the organization. These permissions are often preferable alternatives to the “View All Data” and “Modify All Data” administrative permissions.

In this lesson, we look at permission sets, and profiles vs. permissions 

In this lesson, we go over record and field access levels.

In this lesson, we refer to the Salesforce Security Model Diagram, and how the Org-wide defaults specify the default level of access users have to each other’s records.

In this lesson, we look at the relationship between various objects, first referring to the Sales Objects ERD Diagram found within the SOAP API Developer Guide. We then use the Schema Builder to further look at the relationship types between Account, Contract, Contract, Case and Opportunity.

A role hierarchy represents a level of data access that a user or group of users needs. The role hierarchy ensures that managers always have access to the same data as their employees, regardless of the organization-wide default settings. Role hierarchies don't have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.

In this lesson, we grant the ability for administrators to log in as other users in our org. We then adjust the Session Settings to unlock the Force relogin after Login-As-User setting. We also adjust Jim Doe’s profile to make him a Lightning Experience user.

In this lesson, I place myself at the bottom of the Role Hierarchy and place Jim Doe above me as my manager.

We then demonstrate how Jim is unable to create a new Account record.

Ownership-based sharing rules allow for exceptions to organization-wide default settings and the role hierarchy that give additional users access to records they don’t own. Ownership-based sharing rules are based on the record owner only.

In this lesson, I create a criteria-based sharing rule. We specify that any accounts that are named Sony or have a Start Year of 2018 should be shared with the Director, Channel Sales Role and Subordinates. We also create a new ownership-based sharing rule to better fit our scenario and to replace the one we created in the previous lecture. We then adjust an account record to verify that the sharing rule worked as intended. 

In this lesson, I manually share an account record with other users, after first confirming through the Sharing button that they don’t already have access through some other means.

In this lesson, we look at Team Access – specifically related to Account Teams, Opportunity Teams and Case Teams. We enable Account Teams and Opportunity Teams. We also cover how to specify default Account and Opportunity Teams. 

In this lesson, we go over record ownership and queues. 

Every record must be owned by a single user or a queue. The owner has access to the record, based on the Object Settings for the owner’s profile. For example, if the owner’s profile has Createand Read permission on an object, but not Editor Delete permission, the owner can create a record for the object and see the new record. However, the owner won't be able to edit or delete the record. Users higher in a hierarchy (role or territory) inherit the same data access as their subordinates for standard objects. Managers gain as much access as their subordinates. If the subordinate has read-only access, so will the manager. This access applies to records owned by users, as well as records shared with them. 

Queues help you prioritize, distribute, and assign records to teams who share workloads. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue. 

In this lesson, I demo how to create a public group. 

In this lesson, we run the Health Check for our org. I address one of the issues listed in the report and then re-run the Health Check to see the impact on our scores.

In this lesson, I enable the Account Owner Report. We then run the report while logged in as Jim Doe. I also removed Jim Doe from my Default Account Team and also removed my Role designation on my user account to block access to my records for Jim. This was to demonstrate that although Jim does not have access to my account records and our org wide defaults are set to private on the Account object, Jim is able to see limited details about the accounts in our org, such as account name, owner and last updated date.

In this lesson, we introduce Record Types to the Asset object. We create Record Types for Medical Equipment and Office Equipment. We discuss how Record Types are leveraged to associate Page Layouts by Profile, as well as Picklist Values that are available. In addition, we discuss how Record Types can be assigned on the Profile and a Default Record Type designated.

But we don’t stop there. We look at assigning Record Types by Permission sets. I then share a help article that contrasts the ins and outs of what happens if a user either has the Master Record Type or a Custom Record Type on their Profile and the various combinations of Record Types assigned via Permission Sets.

In this lesson, we explore the use cases and functionality of Delegated Administration. Use delegated administration to assign limited admin privileges to users in your org who aren’t administrators. For example, let’s say you want the Customer Support team manager to manage users in the Support Manager role and all subordinate roles. Create a delegated admin for this purpose so that you can focus on other administration tasks.

In this lesson,  we explore the territory hierarchy and its single dimensional, additional hierarchy. Which can be structured by business units or any kind of segmentation in a hierarchical structure.

In this lesson, we go over how to enable territory management.

In this lesson, we look at the various security settings available under Territory Settings:

• Account Access

• Opportunity Access

• Case Access

In this lesson we create the following Territory Models:

• This Year

• Next Year

Now that we have created Territory Models, it’s time to create Territories for them. In this lesson, we create four Territories for the This Year Territory Model:

• Western

• Eastern

• Northern

• Southern

We assign each of these Territories the Type of Geographic.

You can assign accounts either manually or by running Territory Assignment Rules. In this lesson, we look at the implications of both.

In addition to accounts, users can also be assigned to multiple territories. In this lesson, we assign users to the Western and Eastern Territories in our org.

In this lesson we learn about customer scenarios for territory management. Only one Territory Model can be active in an org.