Pass Salesforce Certified Sharing and Visibility Designer Exam in First Attempt Easily

Declarative Sharing

1. 1.0- Declarative Sharing Introduction

This is Section One: Declarative Sharing. And this is the introduction lecture as per the official Salesforce Certified Sharing and Visibility Designer Exam Outline. The exam topics are classified into three sections: declarative sharing, performance and scalability, and programmatic sharing. This is the Declarative Sharing sectionthat has 76% exam question weight. So if the exam has 60 questions, this section alone will have around 46 questions. So needless to say, this is themost important section of the exam. As you can see, these are the objectives of this section, and the lectures that will cover these objectives in this section include object and feed level security, which is the most important security layer in Salesforce. Without object-level security, nothing can be done in Salesforce. I will explain these in detail, and I will also explain about profiles, permission sets, and permission groups. And then we have decorative features for data access. These are all the features that allow us to open up record access, like sharing rules, manual sharing, team sharing, and so on. Then we have access. Grant share and maintenance tables. These are the different system tables that store all shared information. To be able to understand how sharing works under the hood, it is critical to understand these system tables. This lecture will explain these two tables and their use in detail. And then we have team sharing, which is account opportunity and case teams. This is one of the sharing features that can be used to open up bracket access. This feature will be explained in detail with examples on Salesforce.org. This section also has these objectives, and to cover them we have these lectures List of Use andReport and Dashboard Folders and Access where I willexplain the sharing mechanism and list of views andhow to share reports and dashboards using folders. We also have roles and roles hierarchy, where we will create a complex road hierarchy and use it to open up access. We also have community user security. Here we will build a community and explain in detail the different community licenses, which are Custom Community, Customer Community Plus, and Partner Community, and which sharing features each licence type offers. For example, the Customer Community License does not allow roads and road hierarchy. So what should we use instead to open up record access for this licence type? In this lecture, everything will be explained in terms of community sharing and details in this lecture.To continue, we have these objectives, and to cover them, we have these lectures Enterprise Territory Management, where we will configure and build a full territory module and open up access using IT Data Storage and Residency Solutions, which include features like Protected Customer Metadata Type and Protected Custom Settings encryption using the Classic Encryption and Shield Platform encryption. We will also discuss how to validate sharing and visibility and the various methods for doing so. And finally, we will talk about files, how to share them, and how to secure them. Now let's get started with the declarative features. Thanks for watching.

2. 1.1- Object and Field Level Security

This is Section One: Declarative Sharing, and this lecture is about object and feed-level security settings. The topics of this lecture are object-level security, feed-level security profiles, permission sets, and permission set groups. profiles, permission sets, and permission set groups. Considerations and Limitations Before talking about object and feed level security, profile, and permission sets and permission set groups, let's first talk about how Salesforce security is structured. We have different layers that we need to know about. These layers are organization, object, field, and record. The very first layer of security is simply the Organization Login Security, which specifies when, where, and how a user is allowed to log in. This is configured through many settings like loginIP, login hours, IP ranges, and so on. After all, before accessing anything in Salesforce, one needs to log in; once logged in, The second layer of security is object-level security, which determines whether a user has access to a specific object. And within the object level security, we define the feed level security, which indicates which fields they can see on that object and which actions they can do on the field. For example, object and field-level security layers determine if a user is allowed to see the lead object or not, and within this lead object, what fields this user can read and what fields they can edit. Once the object and field-level security are specified, the third layer is the record-level level Access.This is also called sharing or salesforce. This specifies which records a user can see for a given object. The way this whole thing works is that as a user is attempting an action, Salesforce will evaluate each layer of security by itself. For example, to edit the Type field on an account record, you need to be able to log in to the ORG, and then you need to have edit access on the Account object, and then you need to have edit access on the specific field that you are trying to edit. And truly, you need access to that specific account record. As a summary and from an architect's point of view, data access in Salesforce falls into these three layers. But the two main layers are object-level access, which includes feed-level access. This is the topic of this lecture, and the second layer or category is record level access, which is the topic of another lecture. Before talking about object and field-level security, let's briefly talk about the Organization Security layer, where some settings can be applied to restrict access to Salesforce. These include login hours and login IP ranges. Login hours can be set per profile, and it is used to specify the hours when users of this profile can log into Salesforce. On top of that, you can also set the login IP range addresses from which users with this profile can log into Salesforce. Users outside the login IP range cannot access Salesforce login IP ranges but can also act on each and every request. To do so, we have to go to the setup menu, and then we have to search for and select session settings, and check the box that says "enforce login IP ranges on every request." If you don't select this option, login IP ranges are enforced only when the user logs in. Now, let's jump into object-level security. As you are well aware, in Salesforce, all data is organised into something called objects. Objects are equivalent to database tables, and what makes an object are two things: fields, which are equivalent to columns and databases, and records, which are equivalent to rows and databases. Of course, there are tonnes of other things that define an object in Salesforce, like automation, validation rules, and many other things. But these two are the base of an object in Salesforce. The term "object level security" refers to your ability to do actions on a specific object. This action can be read, created, edited, and deleted. Object level security is configured for each and every object independently, and it is also known as "object cred" or sometimes "Crud." Cred and C-R-U-D cr, as you guessed, itstands for create, read, Edit and Delete. And sometimes we use update instead of edit. You can think of object-level security as your tool set or gears for each object. As an example, outside Salesforce, if you need to see something, you need eyes. If you need to erase something, you need an eraser. Eyes and erasers are equivalent to object-level security on a specific object. They don't tell you what exactly you can see or erase, but they provide you with the ability to do so. Object-level security can be set in the profile or through a permission set and a permission set group. These are the tools that we use to configure object-level security. Credentials or object-level security are applied to specific tables. As you can see, this is a table—which is equivalent to an object in Salesforce. It has plenty of fields, and then it has plenty of rows. If you have full access to this object, you can read its records or rows. If you have edit permission, you can edit records for this object. We don't say which exact records you can, but atleast you have the tool to read or to edit. So, if I go to a profile and remove read access to the account table or the account object, users with this profile will be unable to read any accounts. It does not matter who owns these records. If you don't have the necessary access to an object, you cannot read anything. After all, if you do not have eyes, you cannot see. If you don't have an eraser, you cannot delete, and so on. Now, on the other hand, feed level security determines access to specific fields and the object—in other words, columns and the database. So, assuming that you already have access via object cred, you can hide specific fields in this table or object by using field level security, or FLS, for short. With FLS, there are two permissions that you can set: read and edit. This is an example of the AccountObject using only a subset of fields. Let's say that a profile has read access to the Account object, and we want to prevent this profile from reading specific fields, like the field revenue. In this case, we go to the profile and remove the read permission from that field. Now, even though the profile has read access on the object itself, we can specify some fields as hidden by removing the read permission from them. Or we can specify them as read only by removing their added permission from them.It is important to note that if a user does not have account object feed access, he or she cannot see any field, regardless of account field level security. Finally, even though the profile has read access as object level security, this does not mean that the user who has this profile can read all accounts. It only means that this user has the ability to read account records, but not to know which specific records. This is covered in the sharing lecture. Now let's talk about the profile. A profile contains the baseline permissions of a user, and a user cannot exist without a profile. This is not the same as a role because we can have users without roles. A profile defines a user's ability to perform different functions in Salesforce, including accessing records and the way the records are displayed. Profiles are tied to a user license, and the whole idea of this is to determine which objects exist in the profile based on the licence itself. So if a licence allows access to leads, then lead object-level security will be present in the profile. On the other hand, if a licence does not allow any access to some objects, like, for example, the platform license, then these object level security settings for these objects will not be in the profile. The profile contains different settings that the user will have, like app and system permissions, access to data like organisation access, object thread and feed level security, and the UI so that the user can see which applications, which tabs, which page layouts, and which record types. By default, Salesforce comes with a list of standard profiles. These are shipped with the product. To see the list of all of these standard profiles, please click on this link. You can also see this list in Salesforce.org itself by going to the setup menu and searching for profile. And note that a custom profile and its settings have a checkbox under the custom column when you are viewing the list of profiles. Currently, there are two interfaces for profiles in Salesforce. These are the original profile user interface and the enhanced profile user interface. The original profile user interface has all of the settings on the same page. It also has related lists, and sometimes you will have to click on a link to go to the other settings, like the field level security of a specific object. On the other hand, the enhanced Profile user interface lets you search for any setting, and it can also take you to the page of the setting. For me, each one of these has its own pros and cons. It's much easier to be able to search for a setting on the enhanced profile, but at the same time, it's also easy to have all of the settings on the same page. At the end of the day, it's your own preference. Note that you can change the profile user interface by going to the user management settings and setup. Let's now jump into Salesforce to show you the profile object-level security and feed-level level Security.Okay, so I'm now in the ORG, as you can see; I have an application for this course. We will go through this application and the course. Now let's go to the setup menu, and we will go to the users. As you can see, I have this list of users. So these will be used throughout this course. Each one of them has a profile and a role. You can see that this one doesn't have a role because it's not required to have a role for a user. For this demo, I will choose another user, which is Jessie Miller, and then Jesse is part of this profile, and she's locked in on this browser. So you can see on top that I have Jesse. Now let's go to the profiles, and let's open this. So, this is the profile of Jessie. As you can see, it's a custom one because you can see this check box checked on the custom column. And this is the list of all of the profiles. If I don't have this checkbox, this means that this is a standard profile that comes with the system. All of the profiles at the beginning are standard. There are no customs. And if I need to create a custom profile, I need to click on the standard one, and then I need to clone it. There is no way to create a custom profile without a standard one. So this is the list of the standard and the custom profiles. Let's click on a standard one. Now this is the profile that is the original one, because all of the settings are on the same page. So I can scroll down all the way, and then I can see all of the settings on this page. I can also see that I have some related lists, and if I go to some of these settings or permissions, they need to go to another page to be able to be configured. I cannot configure them from that page. Now if I need to clone this profile, I need to click on this button, and this way I can create custom profiles. Note that each one of these profiles has its own licence associated with it. This licence will determine what permissions I have on this profile. So if this is a platform license, I will not have access to, let's say, the court object. But because this is a Salesforce full license, I have access to all of the objects. I go back to the list of profiles. And then if I click on Jessie's profile, you can see that I have the same thing because this has been cloned from another profile. And note that I have the description field added because this is a custom profile. Now let's see how to change the user interface of that profile to the enhanced view. I need to go to the user management settings, and then you can see I have this toggle to enable the enhanced profile user interface. Now, going back to the profile, you can see that the same profile is there, but the interface is now different. So now this is more structured. But as you can see, I don't have all of the settings on the same page. If I need to go to the object settings, I need to click on this. Or I can search on the top; I can search for the object that I want, and then I will go directly to that object. So it's all dependent on your preference. You can choose either one of these two interfaces. Now I will go back to this customer profile and then let's change the object-level security. And then later on the field level of security, if I go back to Jesse's login, you can see that Jessie now has access to the account object because she can see at least one account, which means that she has the eyes for the account. She can see the records of the account object. Can she edit? Let's see if she can. Yes, she can. So if I go back now to the profile, and this is the profile that is associated with Jessie, if I click on Edit and I go down, there's a section that only lists the object cover security for the different objects. You can see that the account has access to read, create, edit, and delete. What happens if I click this one? If I click this one, all of these will go, because I cannot create if I cannot read, I cannot edit if I cannot read, and so on. So let's do that, and let's see what would happen.Going back to Jesse, let's click on Contact, and then let's refresh. You can see that the Account tab is even gone because I don't have read access to the account. I cannot even see the tab itself. It's all gone. Going back now, let's only add read access. Now the account tab is back. I can see the account, but I don't think I can edit it because Jesse or the Profile of Jessie does not have edit access on the account object. So if I click on this account, you can see there is no Edit button on the top right. I cannot even go to the details page and double click. Nothing is there. I cannot edit this account. The same thing goes for the others. So, if I do that, Jessie's profile can now create accounts, but Jesse cannot edit them. Same for the deletion. Note that I have these two here. This is primarily the case if I select View Alland. Modify All: One of the permissions and the profile level that determines record access is Modify All. If I click on "View All," this will mean that Jesse or the profile of Jesse can view all of the records of this object, regardless of the sharing rules or of all of the sharing settings. This is the edit access if I click on it or check it. So these are the only two ways on the profile level to enable record access. There's also one thing that we can use to enable record access on the profile, which is the option to view all data and to modify all data. This is not applicable to each one of the objects, but it's applicable to all of the data as a whole. org. We will talk about this after I show it to you now this.So if I click on View All and then click on Save, this would mean that Jessie can now see all of the accounts in the system, regardless of the sharing rules or the sharing access. This is the same thing for the edit. So if I check the "Edit All" Modify All" box, you will be able to edit all of the accounts. Another way to do that, but this is, as I said, applicable to all of the objects, not just specific ones, is to view all data and modify all data. So if I click this one, Jessie will be able to see all of the records in the system. This is mainly for the admin, not for users. And the same thing for the "modify all data" option. Once I click on this one, you can see that many other permissions should be checked because they are all related to that permission. You must have all of these permissions to be able to modify all data. And now let's talk about feed-level security. Feed-level security is also accessed on the profile level, but it has its own link. So if you are on the old user interface, you have to go to the FLS section, and then you have to click on the view link of the object in question. So, as you can see on the right side, I have read and edit options and I have all of the fields of this object. Let's say that I want to change the FLS access for the Website field. You can see that I can specify either read or edit or both of them. I cannot edit without reading. So if I select this, this will be selected by default. What happens if I do that? There is no lead and no editing permission. If I do that and go back to the now page, let's refresh this. You can see that there would be only one account because I removed the view all option, but this account now doesn't have access, or just doesn't have access, to the website. Let's refresh this; make sure it's not there. Yes, there's no read, so it should not be there. So refresh and they should go. Okay, so same thing can be set for the edit. There's just one thing that we need to make sure that we understand. So if, let's say, I go back and select both of them, there's another setting that deals with the field visibility, which is mainly on the object level on the page layout. So, if I go to the okay, let me return to Chrome, which is the admin, and then let me return to the object manager, then account, and then page layout. There's an option on the page layout that we can use to specify the visibility and the added access on the page layout section, not on the FLS table. So you can see now that I have only read what is required. So these are not the same as FLS. These are only applicable to this page layout. So these are only applicable to this page; they are not applicable to, let's say, reports or dashboards or API access or any of these other accesses. So this is much weaker than the FLS. But I can do this. So let's now cancel this, and then I will refresh this page. You can see that website is there, but I cannot edit it. So if I go back to this page, I know that I have in this field the read-only check post check, which means that I cannot edit this field on this page. But if I do this and then save now, I will be able to edit this field because the page layout now allows me to do so. Okay, so there's a difference between FLS and the page layout field access. FLS is applicable on everything in the system, but the page layout field access is only applicable on the page layout. This is the main difference between these two. Now, let's talk about permission sets. As its name implies, a permission set is simply a set or collection of permissions that can be assigned to a user in addition to the user's profile. A permission set expands the user's permissions and gives extra permissions. You can give as many permission sets as you want to a user, but a user is limited to only one profile. A Permission Set's settings are almost the same as its profile settings, but a Permission Set can be directly assigned to a user to extend the user's permissions without changing the user's profile. Consider a permission set to be a nearly empty profile from which you can select and assign permissions to a user in order to expand the user's permissions. A Permission Set Group, as its name indicates, is simply a collection of one or more permission sets bundled together. Users assigned a Permission Set Group will receive the combined permissions of all the Permission Sets in the group. A Permission Set can be part of more than one Permission Set group. Just like a permission set, many permission setgroups can be assigned to the same user. When a permission set is updated, all permission set groups that contain it are also updated. And finally, there is a feature called Permission Set Muting that is used to remove the permissions from a group. This is a permission set. Group example. Suppose that you have users in your sales department. With these requirements, one uses Sales Cloud analytics templates and apps to create, edit, and delete surveys. Three can create, read, edit, and delete accounts and opportunities and create list views and reports. Without Permission Set Group, or PSG, you can create many permission sets and assign them one by one to the users. But now with PSG, the three permission sets are created once, but they are bundled under one permission set group that is called Sales Staff User and that is assigned to the users. A Permission Set group will save so much time as you can now create a bundle of permission sets and assign them all to one Permission Set group. And this Permission Set Group will be based on the tasks that a user performs. So in this case, I don't need to assign each permission set to a user. Each permission set is assigned to a Permission Set group that I create once for each user. Muting is another feature of Permission Setgroup. Let's use the same example we had on the previous slide with permission set groups. Let's say that we want to remove the Delete Permission on Account and Opportunity from the Permission Set group. For that, the muting option comes handy. This feature removes access to the permissions and questions from the Permission Set group. To remove the delete permission on account and opportunity, you can create a Muting permission set within the permission set group that has the delete permission on account and opportunity. This will remove the account and the opportunity to delete permission from the permission set group. Note that you can have only one muting permission set and a permission set group. Now. Why should we use permission sets and permission set groups instead of only profiles? One of the constraints of a profile is its inability to provide the appropriate mechanism for scalable permission assignment. And this is due to the one-to-one relationship the profile has with the user. Let's give an example. Imagine a sales user being granted a specific profile. But this user needs access to features that are not in the profile at that stage. If we create a profile just for this user, then clone it to another profile, add permissions to that profile, and assign this new profile to that user, we will end up with a plethora of profiles for different users who require different features. That's why we should use permission sets and, more recently, permission set groups. Instead of creating endless profiles, permission sets and permission set groups are used to avoid the creation of so many different profiles that are only slightly different. On top of that, Salesforce is pushing for permission set groups to be the main source of permissions instead of a profile. A profile may be created without any permissions in it, but the main permissions can come in a permission set group. And also, the "muting" feature makes it much easier to revoke permissions. You can click on this link, and then you can see how Salesforce is pushing for permission set groups. Now let's jump into Salesforce to show you permission sets and permission set groups. So I will go back to the.ORG Let's go to the setup menu, let's go to the profiles, and let's go to the custom standard user profile that is assigned to Jesse. And we will get rid of the edit, create, and delete permissions on the account object. Now if I go back to Jesse, you can see that Jesse can only read accounts. She cannot edit; she cannot delete. I need to refresh this page. Now, as you can see, she cannot edit and she cannot delete. I will now create two permission sets. One for editing the account, and one for deleting the account. So let's call this one an "Edit Account," and I will have the enhanced view. Let's go to the account object, and then let's enable the edit account object level security, and then I will do the same for the delete. Okay, so now I have these two permission sets. So if I click on the edit button, I can assign this now from this page or from the user page, where I can click on the Manage Assignments button and then add an assignment and assign it to Jessie. Or I can go to the user, and then I can assign permission sets from the user object. The first ListView is the permission set assignment. So I have the edit. Now I will also add the deletion. Now if I go back to Jessie's.Org and then if I refresh this, you can see that she will be able to edit and delete this account or any account that she has access to and also delete.Now let's bundle these two into a permission setting group. First, let's remove them from Jesse's user record, and we will create a permission set group. Of course, this is just an example. You can create your own permissions-set group based on a role or a function that you need. But this will be just an example. as you can see. Now I have two options. I have either an option to add a permission set to that group or another option to add a mute link permission set. So let's add these two permission sets to that group: Delete account and Edit account. Okay, so let's go back to the permission setgroup, and then you can see it there. So I now have these two permission sets. Inside this permission sets group, I can also add others, but I don't need to do that now. Okay, so this is what I have. Now, I can assign this to Auser just like any other permission set. But instead of assigning each single permission set to a user, I bundled them into a permission set group called "Edit and Delete Account." And then I assigned this permission set group to the user. So if I go back to Jessie's page and if I refresh because I removed the two permission sets, she will not have access to the edit or the delete buttons. Now I need to go to "Manage Assignments" and I need to assign this PSG to Jesse. going back to Jesse's page refresh. Now she will be able to edit and delete. Okay, let's now do something. Let's go back to the permission set group, and let's add a muting permission set. So if I click on this one, this will add permissions that will be used to mute the permissions of the permission set group. So let's choose the default one. This is the one. And now let's say that I want to mute the deletion of accounts. So if I go to the account object settings, I need to select under "Muted" the Delete permission. Notice that once I selected this, the Edit permission did not get selected automatically because this is the Mute permission. But once I clicked on this, modify" got automatically selected. Because if I cannot delete, of course I cannot modify everything. Now let's go back to the permission site group. So, if I go back to Jessie's page and refresh, you can see that she can now only edit. She can no longer delete. Why? Because we added a muting permission set, that will take away the deletion permission. So if I refresh this page, you can see that edit is there, but delete is not there.Now, let's talk about the difference between a profile and a permission set when it comes to the available permissions. As you can see, on the left side we have the enhanced view of a profile, and on the right side we have the same enhanced view. But this time, the Apollo mission was set. What's the difference between these two? You can notice on the bottom right side that there's a gap. These are all of the permissions that are missing from a permission set. Let's see these in details. This is the full list. The most important permissions from this list are the page layout assignment, the login hours, and the login IP ranges. Of course, the others are also important, but these three are the most used ones in this list. Finally, as we now know, a profile gives the baseline permissions to a user, and a permission set grants additional permissions on top of the ones granted by the profile. So, to conclude about profiles and permission sets, the combination of these two, be it one profile with many permission sets or permission set groups or groups including muting Permission sets revoke permission; the combination of these would give us the final user's allowed permission. Now, some considerations and limitations that you should be aware of when it comes to profiles Standard profiles can be edited in a very limited way. The idea is that standard profiles will remain the same and therefore cannot be edited in an extensive way. To overcome this, you will need to copy the standard profile, and this way you can fully edit the resulting custom profile. And when a profile is cloned, the profile licence cannot be changed. It is the same as the source profile. Each profile is tied to a licence that determines the different settings and permissions in that profile. Also, we cannot create our own profiles without cloning existing ones. And finally, on a new user page, the user licence determines the profiles that can be selected. The profile depends on the licence selected. When it comes to permission sets and permission set groups, you should be aware that permission sets are used to only grant XL permissions and not revoke permissions. There is no way for a permission set or permission set group to revoke profile permissions. It is only increasing the permissions. A permission set group can only contain one muting permission set that is created within the group itself. You don't create the Muting Permission Set outside of the Permission Set group, but within it. And finally, you can see the permission result of a Permission Set group including the combination of all of its permission sets minus the permission of the one muting permission set, if any. This is the summary. In this lecture, we talked about the security layers. We talked about how Salesforce has three security layers. Specifically, the objects and field of the organization, followed by the sharing. We talked about each one of these. Organization object level and field level We talked about profiles, about permission sets, about permission set groups, and finally, we talked about the user permission, which is a combination of the permissions of the profile and permission sets. And that's it for the object and field-level security settings. Thanks for watching.

3. 1.2a- Declarative features for Data Access

This is section one declarative sharing and thislecture is about declarative features for data access.The topics of this lecture are record ownershipand queues profiles and permission sets permission includingview all data and modify all data organizationby defaults, road hierarchy sharing rules, manual sharing,team sharing and territory hierarchy.If you recall from the previous lecture we explainedobject level security or Cred and field level security.Object level security specifies whether a user has accessto a specific object, which fields they can seeon that object, and which actions they can perform.Can the user read records of this object?Can the user create records?Can the user edit records?Can the user delete records?Object threads are more the functions and actions that theuser can have and do on and to an object.We gave the example of having eyesto see and an eraser to erase.The eyes and erasers are needed as baselineobject lever security is given with profile andpermission set on top of that.Feed level security deals with which fees canbe read and which can be edited.Both object and field level security do notspecify which records can the user access.They don't deal with records well except for the viewall and modify all permissions on each object and viewall data and modify all data across all objects.By default, an object thread are appliedto the records that a user owns.Let's say that we have cred access to an object.Which records can we read them?Well, by default, credit is applicable to therecords that the user owns and nothing moreuntil we open up access by sharing.So in this table that we can see onthat slide, if record one is owned by theuser, then the correct settings and feed level securitysettings will be applied on that record one.But to give the user accessto more records, sharing is needed.So in conclusion, object level security deals with theactions a user can have on an object.Feed level security deals with the field thata user can and cannot read and edit.On the other hand, sharing and record accessdeal with which records can a user access?In this lecture we will go through allthe declarative settings that can be used toopen up record access in salesforce.Each and every record must be ownedby a single user or a queue.The owner has access to the record basedon the object settings for the owner's profile.For example, if the owner's profile has create andread permission on an object but not edit ordelete permission, the owner can create a record forthe object and see the new record.However, the owner will not be able to edit ordelete the record queues help you distribute and assign recordsto teams who share workloads queue members and users.Hire an error hierarchy can access queues from listviews and take ownership of records in a queue.Let's now jump into Salesforce toshow record ownership and queues.I'm now logged into the.org using my admin account.So as you can see on the top right, this ismy user and this is an admin user that has thesee all data and modify all data, which means that Ican access all of the records within Salesforce.As you can see, I'm using thisapplication and this application has these tabs.It has the account contact opportunity and case tabs.These are all standard objects and it also has twotabs for two custom objects called Project and Invoice.We are also using the Reports and the Dashboard tab.Now, if I go to, let's say, the Account taband if I select any one of these accounts, youcan see that this account has an owner.So this can be either a user or a queue.So this is the key tounderstand the sharing in salesforce.There is no record in Salesforce thatcan exist without having an owner.Each and every record within Salesforce should have an owner andthis owner can be either a user or a queue.Now, if I go to any other record youcan see that it also has an owner.But this can be a different userand same for the custom object.You can see that this also has an owner.If I go back to the tab, I can seethat I have the list of all of the projectsand I can also add a column for the owner.Now, how can we create a queue for that?Let's go to the setup menu and let's search for queue.We have to click on View and then wehave to have a label for the queue.And then the API name can have an emailand then we can choose to send an emailto all the queue members or not.So this is the case.If, let's say we received a new recordon that queue, who would receive the email?It can be each and every one of themembers or it can be the queue email only.So this is the queue.The first step is to define the object of the queue.So these are all of theavailable objects that support queue.We mostly use cues for cases.So if I go to Case and then I need toselect it and we also use it mostly to leads.Of course you can use it toany other object that is supported.Like Project is also supported and I'massuming the invoice should also be supported.So let's go with the case.So let's call this one and let's add the users to it.We can add users, we can add roles, rolesand subordinates and we can add public groups.I would choose random users.Click on save.Now if we go to the Casetab, that will show the case object.I can go to any one of thesecases and I can change the owner.You can see that I can choose an owner tobe either people, which is users or queues, and Ican choose to send an email or not.This will send an email to the queue emailor to each one of the queue members.Now the owner is a queue and I can goback and I can make the owner a user.This is the key for this demo.I just showed you that each and every recordin Salesforce should have an owner and this ownercan be either a user or a queue.Record level access, which is called sharingin Salesforce, determines which records a usercan see for a specific object.But before opening up record access, object levelsecurity should allow us to access this object.So if, for example, a profile does not have theread access on the account object, then there is noway for users of this profile to access account records.These are the different ways to open up record access.First of all, we have the authorization bydefault, which is the only setting from thislist that can restrict record access.It specified the default access level forall users for this specific object.And then we have the role hierarchy.We also have sharing rules, manual sharing,team sharing and territory hierarchy access.Note that in Salesforce, record ownership and fullaccess are interchangeable and provide the user withthe highest level of access to a record.As we mentioned, profiles and permission setsprovide object level security by determining whattype of data users see and whetherthey can edit, create or delete records.This is the credit permissions on an object.Profiles and permission sets also control fieldlevel security which determine the field withineach object that users can access.For example, a SSN field can be hidden in allprofiles except for a single profile for each object.The view all and modify allpermissions ignore sharing rules and settings.These two permissions allow view or editof all records of this specific object.On top of that, we have the view all dataand modify all data permissions which allow access to the.orgrecords and are not limited to specific objects.Organization by Default Owd sharing settings specify the defaultlevel of access users have to each other's. Records.Owd are the only way to restrict record accessand you use Owd settings to lock down yourdata to the most restrictive level and then usethe other record level security and sharing tools toselectively give access to other users.For example, let's say users have objectlevel permissions to read and edit opportunitiesand the organization by Default sharing settingfor opportunity is read only by default.These users can read all opportunity recordsbut cannot edit any unless they ownthe record or are granted additional permissions.As an architect, owd is the first sharing thingto be configured and an architect needs to askthe right questions to be able to set theright Owd settings for each object.For each object the Owd can be a private.This is the most restrictive levelwhere records are only accessible throughownership and other sharing mechanism.Public Read Only all records are read onlyfor any user that has the right object.Clever security Settings public Read Write all records canbe edited for any user that has the rightobject level security Settings public leads right and transferonly available for case and leads and it isa step above the public lead right as itallows transferring the records to another user.Public full Access this is only available forcampaign and it allows view, edit and transferand delete on all campaign records.And finally we have the control by parent.This is mainly for the master detail object on thedetail side objects and a master detail relationship that areon the detail site do not have their own Owdbut they are controlled by the master side object.A user can perform an action like let's say view, editor delete on a child object record based on whether thisuser can perform the same action on the parent.So in other words this ismainly controlled by the parent.If you have on the parent object this permissionyou will have it on the chart object.Let's now jump into salesforce toshow profiles, permission sets and Owd.I will go to the set up menu and beforetalking about profiles and permission sets let's talk about Owd.To access the Owd we need to go to thesharing settings and this is the menu that will allowus to access the Owd as well as different sharingtools like sharing rules, like other settings that we canset like roles and role hierarchy options.But for now we will talk about the Owd.As we mentioned, the Owd is thebaseline of the sharing for each object.It can be private, public feed, right and so on.So what I will do, I will make the Owdfor all of these objects private except for the account.I will make it publicly only which means that anyuser will not be able to access any, let's sayopportunity, case, project invoice record as long as this userdoesn't have access to it or doesn't own it.So I clicked on edit go and do that.So I will make account and contracts publicly andthen I would go to the case, I wouldmake it private opportunity private contact is controlled byparent or it can be private.So this is mainly controlled by the account or Ican say no, I needed to be a private model,let's keep it controlled by parent and then I havethe project and the invoice invoice it was set toprivate and project does make it private.Now, if you click on save, what will happen?In the background, there are many tables that will changeand this will set these objects to the new owd.So I need to wait for an email from salesforce.This email will mention that the owd has been changed.And once this email is received, this means thatthe new owd is applied to the system.As you can see, this is the email and thiswill tell me that the new owd is now set.Okay, how can I verify this?Let's go to, let's say, the invoice object.It has the list of all the invoicerecords and then we will log in byusing another user on the firefox browser.So this is using the lizaking user.Let me refresh this.Let me see Lisa king user and the setup menu.Okay, so you can see that Lisa kinghas this role and she has this profile.Okay, so now if I go back to the invoiceobject, you can see that I have this list ofinvoices and these are owned by these users.One of the invoices is owned by Lisa.And because we set the owd of the invoice objectto private, lisa can only access this one record andany other record that she can access through sharing.So to verify Lisa, the other way that she can getother records at that stage is through the role hierarchy.Let's go to the role and let'ssee Lisa's role and the three.Okay, so Lisa's role as finance manager, which is thisone, so she can access her own records and shecan access records of any role underneath her.There's no other roles underneath her, which means thatLisa can only access her own invoice records.How can we see that?Let's go back to firefox and let's go to the invoice.And you can see there's only one record.Now, what would happen if, let's say I go tothe admin set up to the admin page, and let'ssay I change the owner of this to Lisa.What would happen in this case?Now, if I go to firefox and if Irefresh this page, this other envoy should be there.I need to go to the old.Now I will have three and onebecause these two are owned by Lisa.Now let's go back and change the owdof the invoice object to public read.Okay, so what will happen now?I need to wait for the email.And once the email is received, this means thatall of the records of the invoice object arenow visible to any user that has access tothe invoice read object level security settings.In this case, liza has access to this.So if I refresh this, I will see all of the records.But Lisa can only edit these two.So let's go to the email inboxand let's see if I got this. Yes.Now if I refresh this, alisa will see all of the invoicesbut she will be able to edit only one and three.Okay?So if I click on let's sayfive, there is no edit option.If I click on one that is owned by Lisawhich is let's say one, this can be edited.Let's go back and let's make this object private again.Now let's go back to the listof users and as you can see.This is my whole list.All of the users that are using this customprofile if I click on this profile and thenif I click on edit you can see theobject level security for these objects like account.Read. Create. Edit. Case.The same thing and then the two custom objects.They have the same thing.So any one of the objects of this application theyhave create, read and edit object level security settings andthis is why Liza can edit her own invoices.Now we will show how to add permissions tothis profile or to specific users by using thepermission sets and the permission sets groups.So what we want to do, we want to give someof the users some special permissions so for that let's goto the role let's say that we want to give somepermissions to some of these we want to give the FinanceManager role or any user in this role two permissions.The first one is to view all of the invoices andthe second one is to delete the invoices and we alsoneed to give users of this role two permissions.Which are the first one is the view allopportunities and the second one is to delete theopportunity and for the Service Manager we want togive the users of this role two permissions.The first one is the view all casesand the second one is to delete cases.For that let's go to permissionsets and let's use permission sets.Instead of changing in the profile and throwing the profilewe will use the permission sets and then we willbundle many permission sets under permission set groups.So let's create six permission sets the first one will beview all invoices so we can give the view all forthe invoice object and we will save let's do the samefor the opportunities and the same for the cases.Now I have a total of six permission sets that Ihave created a three to view all and three to delete.So now let me log in with,let's say the Finance Manager user.I can see that Lisa King is the Financemanager so let's make sure that she's logged in.Yes, she has access to all of the invoices but shecannot delete if I refresh, she will not have access tothe ones that she doesn't have access through sharing.She will only have access to the two that she ownsso she cannot see all of them and she cannot delete.So if I click on one that she owns,you can see that we cannot delete it.She cannot delete it.What I can do, I can go to the user of Lizaand then I can assign the two invoice permission sets to her.But a better way to dothat is through permission set groups.Let's call this finance manager PSG.We will add the two invoice permissionsets, view all invoices and delete invoices.And then I can assign this to Lisa.Okay, so what will happen now if I go to Firefoxand then if I refresh this, two things will happen.I will see all of the invoice recordsand then I can delete the invoices. Okay.And the same thing can happenfor the other permission sets.I can create a permission set group for the sales managerand then I can do the same for the service manager.Let's do it.We need to create one for the opportunities.We created one for the account.Okay, let's do it now.Okay, so now if I log in as one userof the sales manager role, they will be able todelete opportunities and to view all of the opportunities.And the same thing for the otherpermission set group, which is the service.So now I have three permission set groups.One for the finance manager, one for thesales manager, and one for the service manager.Let's see which users correspond to these roles.So we assign the finance manager user.Jack will be the sales manager.And if I go back to check the service manager,I can see that Henry is the service manager.So now if I go and if I log out fromthis user, and then if I log in by, let's say,Henry, henry will be able to see all of the casesand he will also be able to delete cases.Henry is the service manager.So if I go to the cases, I willbe able to see all of the cases, eventhough these cases are not owned by Henry.And of course, Henry can also delete the cases.Now let's talk about how to open up record access.The first thing that we'll talkabout is the role hierarchy.A role hierarchy works together with other sharingsettings to determine the level of access.Users have two records.A road hierarchy organizes your users in athree like structure, just like an old hierarchy.But this is only applicable for record access.Records are shared throughout the hierarchy using thegrant access using hierarchy option and the sharingsettings, users can access the data of allthe users directly below them and the hierarchy.These are called subordinates.In other words, users hire and hierarchy inheritthe same data access as their subordinates.Which means that if the subordinate hasread only access so the manager willhave the same level of permission.This access applies to records owned by usersas well as records shared with them.Let's now jump again into salesforceto show roles and road hierarchy.As you can see, this is the roadhierarchy that I have created for this.org.You can see that I had a president on thetop and then I have finance manager, sales manager, servicemanager, and then I have the Se manager.And then underneath each one ofthese we have different roles.So, role hierarchy works by, let's say we havea record owned by a person, by a userthat belongs to the Western sales team.This record can now be accessed by anyone above this role,like it can be accessed by users of that role.It can also be accessed by users ofthat role and by users of that role.So this is the meaning of the role hierarchy.It's opening up record access to theroles that are above the user's role.So if I'm owning a record, any user above me inthe role hierarchy will be able to access this record.And the access will depend on what my access level is.If I can read this, they can all read this.How this is set up.First of all, this is set up by setting up the tree.And then the second place that we needto go to is the sharing settings place.And the column that we have tocheck is the grant access using Hierarchies.By default, this is checked forall of the standard objects.But we can choose if we want togrant access using Hierarchies to the custom objects.If I click on Edit, you cansee that the standard objects are dimmed.But if I go to the two custom objects thatI have, you can see that these can be changed.If I do this, if I, let'ssay, uncheck these, what will happen?Any invoice record will not begranted by using the hierarchy.So if I uncheck this and save, let's say that wehave an invoice owned by a user of that role.Because we unchecked the grant access by usinghierarchy, this invoice records will not be accessedby users of that role, neither that role.So unchecking this will stopaccessing record through road hierarchy.So let's see this as an example.Let's go to our application andlet's see the invoices tab.So, I have these invoices.You can see that they are owned by these.Lisa is the finance manager.So Lisa is in that role, which means thatthis invoice record, which is invoice one, will beseen by any user and the president role, butwill not be seen by any other user.Let's do something.Let's change the ownership of this to auser of the Eastern sales team role.So if I click on this, you can see I have three.Let's go to David Jones.Before I save, I will log in on the other.org.So let's open the hierarchy again.Okay, so I want to change this to this user andthen I will log in by, let's say the sales manager.So sales manager, we have Jack.Okay, if I go to the invoices, you can see thatJack can access these two and four because he owns them.Now if I go and if I save this,this record will be on now by David.And because we are granting access using hierarchy, once I savethis, any user and the roles that are above the roleof David will be able to access this record.So if I do that and if I go backto this Firefox browser, which is the browser off, youcan see now that Jack can access the third invoice,which is number one, which is owned by David.Before talking about other ways to open up accessto records, we need to talk about public groupsbecause it's a major part of sharing in salesforce.A public group is different than a chatter group.It is a collection of users, roles and soon that all have a function in common.A public group can consist of any one ofthe entities in this list, it can consist ofusers, it can consist of roles, also of territories,and it can also consist of other public groups.So as mentioned, groups canbe nested within each other.A group can be part of any other group.However, don't nest more than five levels asnesting has an impact on group maintenance andperformance due to group membership calculation.Also as a best practice, keep the total numberof public groups for and all to 100,000.As we are aware until now, an organizationby default defines the baseline access of records.We can open up access using a varietyof mechanisms like the role hierarchy access.But what if you want to share records independentlyfrom the role hierarchy but following well defined rules?For that we can tackle the sharing rules.Sharing rules is another way to open up access.It allows for exceptions to Owd settings andthe role hierarchy that gives additional users accessto records they do not own.There are two types of sharing rules.First of all we have the ownership basedand then we have the criteria based.The ownership based sharing rules are based onthe record owner only and records are sharedfollowing criteria based on their owner.For example, we can share all of the opportunities owned bya specific user a with a group called Group B.As a best practice, keep the number ofownership based sharing rules per object to $1,000.This is how to configure ownership based sharing rules.Step one is to specify the name.Step two is to specify that thissharing rule is based on record owner.Step three is to select which recordsto be shared by specifying the owner.Step four is to select the users to sharewith these can be groups role and role andsubordinates and territories and territories and subordinates.And finally, step five is to select the access level.This can be either read only or read write.Criteria based sharing rules provide accessto records based on the recordsfield values, which is the criteria.If the criteria are met one or many field valuesthen a share record is created for the rule.Record ownership is not a consideration in this case.This is how to configure criteria based sharing rules.Step one is to specify the name.Step two is to specify that this sharing ruleis based on criteria and not on ownership.Step three is to select which recordsto be shared by specifying the criteria.Step four is to select the users to share with.These can be groups, roleand subordinates, territories and subordinates.And finally, step five is to select the access level.This can be either read only or read write.Let's now jump into Salesforce toshow groups and sharing rules.Before talking about sharing rules, let's talk aboutpublic groups and let's create a public group.So to do so, we have to go to the publicgroup link in the setup menu and let's create a publicgroup for all managers, roles, finance, sales and Service Manager.So this is a public group that contains these roles.Again, we can add all of these in a public group.We can add role, role and subordinates usersand we can add also public groups.Now let's go to the sharing rulesand let's create two sharing rules.The first one will be ownership based so itwill be based on the owner of the record.And the second one will be criteria based.The first one will be on the invoice object.So I have to go to the invoice object.Now we need to go to the invoice sharingrules and then we need to click on new.We need to give, read and edit accessto the invoice object for all the managers.So let's make it read.This will be based on record ownership.I need to share what I need to sharethe invoices that are owned by all internal users.And then I need to share these with apublic group called All Managers and the access willbe what it will be read and write.Now what will happen in the background?Salesforce will change the sharing settings and then now anyuser that belong to the All Managers group will beable to read and to edit all of the invoices.Now let's do another sharing rule.This time it will be a criteria based sharing rule.Let's go to the project object and then wewill click on New under project sharing rules andthis time we will use a criteria.So let's go to the project object.You can see that I have a list of projects.Let's select one of them.For example, This one.Let's share this project with a group.So let's say red right on this project.So let's say that this is an important project andanyone in the.org should be able to edit this one.So now, because I have this criteria based sharing rule,and because I specified the records that will be insidethis sharing rule, in this case it will be justone, because I only have one project that has thisnumber, this project will be shared with this group andthe shared access will be read and write.Next online we have manual sharing.Manual sharing is not automated like theother declarative data access features like Owd,like rules, like sharing rules.But it gives users the flexibility to share specificrecords with users that need to see them.To grant access to a record, youmust be one of the following users.You must be either the record owner, a userand a role above the owner and the hierarchy.Any user granted full access tothe record and an administrator.To create manual sharing you must be in Classic asthis feature is still not available in lighting, you willneed to open a record within Salesforce Classic.Then click on the sharing button.Then specify with who this record is to be shared.This can be groups, roles and roles andsubordinates and territories and territories and subordinate.Or it can be a single user.And the final step is to specify the access level.This can be read only or read write.Another way to open up access is through team sharing.For account opportunities and cases, record ownerscan use teams to allow other usersaccess to their own records.A team is simply a group of users that work togetheron an account, on an opportunity, or on a case.The record owner adds team members and specifies the levelof access each team member has to the record.So that some team members can have read onlyand some others can have read and write access.So you can choose the role ofeach team member independently from the other.Some team members can have the read access andsome others can have the read and write.We will not have a demo in this lecture forteam sharing because team sharing will have its own lectureand it will have its demo in that lecture.The final declarative feature that we can use toopen up record access is the territory hierarchy.How this works first we need to create our territories.Then we need to assign accounts to these territories.For example, US East, US West andUS Central territories, where each territory hasthe accounts based on the account state.On the other hand, a useris also added to these territories.So now a territory links a bunchof accounts with a bunch of users.This will open up the access of theseaccounts and optional opportunities and cases that areassociated with these accounts to the users thatbelong to the same territory.We will not have a demo in this lecture forterritory management and territory hierarchy because this feature will haveits own lecture which will have the demo.This is it for the declarative features,for data access and this lecture.We talked about different waysto open up record access.Declaratively.We started by mentioning sharing or recordaccess, what it is and which layerit is in, the salesforce security layer.We talked about record ownership andqueues profiles and permission sets.We also mentioned that profiles have the read all and modifyall permissions on each one of the objects and they alsohave the read all data and the modify all data.We talked about Owd, which isthe baseline object sharing model.We talked about role hierarchy, public groups, sharingrules, manual sharing teams and territory hierarchy.This is a very important lecture because it willlist all of the declarative features that will allowus to open up record access.

4. 1.2b- Access Grant, Share and Maintenance Tables

This is Section One: Declarative Sharing, and this lecture is about access grant, share, and maintenance tables. The topics of this lecture are record access calculation grant, database architecture, object tracker tables, object chairing tables, and group maintenance tables. This is one of the most important lectures in this course. Even though there is no direct objective in the exam outline about it, this lecture is required to understand exactly how sharing happens under the hood. It explains what happens when you own a record, when you manually share a record, when you add users to a role, et cetera. It also explains how sharing is happening on the database level and what tables are used to enable sharing. Because you have so many options for managing record-level access, and because some of these options are affected by organisational dependencies, determining which records users can access can quickly become complicated. Every time a user attempts to open a record, run a report, access a list of views, or search for data, Using the user interface or API, Salesforce checks the configuration of its record access features to determine which records this user can access. These configurations can be elaborate, especially in large organisations with hundreds of hierarchy nodes, thousands of sharing rules, and millions of data rules. To overcome this, and rather than checking record access in real time, Salesforce calculates record access data only. When configuration changes occur, the calculated results persist in a way that facilitates rapid scanning and minimises the number of database table joins necessary to determine record access at run time. To begin, let's talk about access grants. When an object has been set to private or public-lead only, which is not the least restrictive option, salesforce uses something called access grants to define how much access a user or group has to that object's records. Think of it this way: when an object's OWD is set to the least restrictive option, something like "publicly available," there is no need to use anyAccess as the default baseline. Access is the least restrictive, and anyone in the ORG can access any record of this object. Each access grant gives a specific user or group access to a specific record. It also records the type of sharing tool—it can be sharing, rule, team, etc. Salesforce uses four types of access grants. First of all, we have the explicit grants, then we have the group membership grants, then we have the inherited grants, and finally we have the implicit grants. The first type of access grant is the explicit grant. Salesforce uses explicit grants when records are shared directly to users or groups. Specifically, Salesforce uses explicit grants when a user or a queue becomes the owner of a record. This is straightforward. As we have seen, each record in Salesforce should have an owner. There's no record in Salesforce without an owner. And whenever a record is owned by a user or a queue, an explicit share is used to grant access to the record for the owner or for the queue. A sharing rule shares the record with a person or a public group, a queue, a role, or a territory. This is when sharing rules are used to share records. Three: An assignment rule shares the record with a user or a queue. A four, a territory assignment, shares the record with a territory. A user manually shares the record to another user, to a person, to a public group, to a queue, to a role, or to a territory. This is mainly manual sharing. And then we have a user become part of a team for an account, opportunity, or case. This is mainly about opportunity and case team sharing. And finally, a programmatic customization shares the record with a user, a group, a queue, a role, or a territory. This is mainly apex sharing. So in conclusion, anytime you see a record assigned using any of the above, know that explicit sharing is used to grant this access. The second type of access grant is the group membership grant. This is used for grants that occur when a usergroup, queue, role, or territory is a member of a group that has explicit access to the record. So as you are now aware, an explicit share is used to grant access to a group. As a result, the type of access granted to groups can be sharing rules, manual sharing, or effect sharing. In this case, all members of a group are granted access using the group membership access grant. So if, let's say, we use explicit sharing to, let's say, share a record with a group, this is explicit sharing. But what about the members of this group? The member of this group will also have access to this record using this group membership grant. As an example, if a sharing rule explicitly grants the sales group access to the Acme account record and Bob is part of the sales group, his membership and this sales group will grant him access to the Acme account record. The third type is an inherited grant. This is used for grants that occur when a usergroup, queue, role, or territory inherits access through a role or territory hierarchy or is a member of a group that inherits access through a group hierarchy. The key word here is hierarchy. So whenever access is granted through a hierarchy, be it role hierarchy, territory hierarchy, or even group hierarchy, inherited grants are used. As an example, if, let's say, we have two users, Alice and Bob, and if the user Alice has a role that is higher in the role hierarchy than the other user, Bob, then Alice can access the same records that Bob can access. This is all through inherited grants. The fourth and final type is the implicit grant. This is used for grants that occur when non-configurable record sharing behaviours built into salesforce, sales service, and portal applications grant access to certain parent and charge records. This includes read-only access to the parent account for a user with access to a charge record. So let's say that you have access to an opportunity. In this case, you will automatically have access to the parent account of this opportunity. access to charge records for the owner of the payment account. Let's say that you own an account. In this case, you will automatically have access to the charge records of this account and access to a community account and all associated contacts for all community users under that account. This is mainly for the community users' access to their parent account. If, let's say, you are a community user, in this case you will have implicit access to your parent account, and then we have access to data owned by community users associated with the Sharing Set. For users in the Sharing Sets Access Group, we will see this in detail in the community lecture. But for now, you just need to know that SharingSet is a way to open up record access for community users, and using Sharing Set will use Simplicity Grants. Now that we know about the four access grants, it's time to know where these access grants are stored within Salesforce. Well, first, the records of a given object are stored in the Object Record Table. This is the table that stores the records of a specific object. Like the account records, the opportunity records, the case records, and so on. Each one of these objects has its own table, and it indicates which user, group, or queue owns each one of these records. Then we have two special kinds of tables: the object sharing tables and the object sharing tables. These are the tables that are used to store both implicit and explicit grant access records. As we said, explicit grants mean access via ownership sharing rules, assignment rules, teams, territory assignment rules, manual sharing, and Apex sharing. An implicit grant means access to an account record when you have access to one of its child objects. It also means access to an account record when you own the account, and it also means Sharing Set access. The other special tables are called the group maintenance tables. These tables store the data supporting group membership and inherited access grants. As we said, a group membership grant means access to members of a group that has explicit access or inherited access. An access grant means access using road hierarchy, territory hierarchy, and group hierarchy. So as a conclusion, explicit and implicit grants are stored as records, and the object sharing tables (or share tables) and group membership and inherited access grants are stored in the group maintenance tables. Once again, an Object Record Table stores the records of a specific object and indicates which user, group, or queue owns each record. This is an example of a query: selectID name, owner name from Project. So in this case, project underscore underscore C is the table that stores the record of the project object. Share tables, or sharing tables, are tables that store the data that supports explicit and implicit grants. They store access granted to users and groups. As a so-called example, select ID, parent ID, user ID, or group name access level row calls from a project's underscore underscore share.So in this case the sharing tableis called project underscore underscore share. In the case of a standard object, it will be without the two underscores. So if, let's say, we want to get the account sharetable, it will be account share without the two underscores. In the middle group maintenance tables are tables that store the data supporting group membership and inherited access grants. They store the list of users or groups that belong to each group, indicating group membership. To know whether a group is a systemgroup used in group maintenance tables, we can use this so-called query: select ID name, developer name type, and owner ID from group. And then you can see that the name field is empty for system groups, and the owner ID is the old ID. So whenever we see a name that is empty and an owner ID that is set to the old ID, we know that this is a system group. For you to grasp the concepts of this lecture, I will give many examples. This is example one. In this example, Maria creates an account record with, let's say, ID equal to 1 for a company called Acme. As you guessed, this is an explicit grant of access, and under the hood, Salesforce creates the Acme account record with ID equal to a one.Again, this is an account object table, and it also creates a record and an account sharing table that has the ID of the record and the user as Maria, withdrawing calls as the owner because Maria is the owner. So, as you can see here, I have the account table on one side and the account sharing table on the other. And then you can see that the match is on the account ID. So on the left side, I have an account ID equal to one. This is the ID of the account record. And then on the sharing table, I have this row. So this row has what, it has account ID equalto a one which corresponds to this account and thenit has the row cause as the owner. So owner is the cause of creating this row, and then it has this, which is mainly the owner of this record. So again, once I create a new account, two things will happen. The first thing that will happen is the creation of this row and the account object table. And the second thing that will happen is the creation of this row and the account sharing table. And the match between these two is the ID of the account. This is example two. This example has manual sharing. Let's say that Maria will share this record manually with Frank, the service executive. Under the hood, Salesforce will add a sharing row for Frank and the account's share table. And the account sharing table now contains two different records or two different entries. One for the ownership. This is mainly the first row that we have seen. And the second one is due to the manual sharing that Maria did. So on the first row, you can see that I have the same thing that we talked about in the previous slide. But now on the second row, I have the row marked "Asmanual," then I have "Frank," and then I have "A." So in this case, Frank will have access to the A-1 record, and the access will be read Android. And the reason for this access is the manual sharing that Maria gave him. So again, the matching record is the A one. In this case, Frank can access A 1, which means that he can access this record. The third example is for sharing rules. An admin creates a sharing rule that shares the sales executive's records with the strategy group, giving them read-only access. In this case and under the hood, a salesforce will add a sharing role that gives the strategy group access to Maria's account, which is called the Acme account. So what will happen once this sharing rule is created and saved? You can see that now we have a new row being added to the account sharing table. This row will have the ID of this account. It will have which user or group will access this account, and the level will be read-only because we said that the rule will only grant read access, and then we have the cause. So this rule will give any user andthe strategy group read access to this record. So anyone that belongs to this group will have VA access to A one.And A one will be this role. Now let's give an example for role hierarchy access. And let's say that the OWD in this example is set to private. We will see what happens under the hood with the role hierarchy. So let's consider this hierarchy. On the top, we have the CEO role. Underneath this role we have thesales exec and the services exec. You have two roles beneath the sales executive: east sales representative and west sales representative. And underneath the services exec We have the service rep. On the right side, we have the different users that belong to each one of these roles. And what we need to know is that once we create these roles, a salesforce will generate system groups in the background to support the record access inheritance that the role hierarchy establishes. These system groups are composed of two things: role groups and role and subordinate groups. So in other words, whenever we add a role, each one of these roles will have two groups in the background, and each one of these groups will have the list of users that belong to this group. Again, these groups are not public groups, they are system groups. We will see this in detail in the role and role hierarchy access lecture. So as a result, we have these six groups that will get created. These are mainly the role groups, and we'll also have six different groups for the roles and subordinates. So in this case, let's say that I want to share a record with a role. Assume I want to share a record with the east sales rep role because we have a group that Salesforce created in the background. This sharing will use this group. And let's say I want to share this record with a role and subordinate group, and the background salesforce creates a role and subordinate group. So in this case, the role and subordinate group for the CEO role will be all of these users. Why? Because it should have all of the users and the hierarchy. Example four is for royal hierarchy access. Assume Maria creates an account record with an ID of 1 and a name of Acme. Under the hood, Salesforce creates a new account record for Acme and an owner sharing row for Maria and the account sharing table. As you can see, I've now added a new row to the account table with the ID 1 and the account name Acme. On top of that, I have a new row on the account sharing table. This row has an account ID equal to 1, and a user group equal to Maria. And the cause of this row is owner, which means that Maria is the owner of the account with ID equal to one, which means that Maria can access this account. On top of that, the record is shared with Markas, an indirect member of Maria's sales executive role group. So this is mainly the other table. So the first table, which is the account sharing table, has the ownership. And the second table, which is the group maintenance table, gives access to Mark as an indirect member of Maria's sales exec role group. Example five is about role hierarchy access and manual sharing. Imagine now that Maria has manually shared the Acme account record with Bob. In this case, under the hood, Salesforce creates a new sharing row and the account sharing table for Bob. So, as you can see on the right side, now we have another row. But this time, this row is close to being equal to the manual user group for Bob. And the access is for the A one, which means that Bob can access the A one account because of the manual sharing. So this is the one account that Bob can access. On top of that, this record is shared with Maria as an indirect member of Bob's East Sales Rep role group. And this record is also shared with Mark asan indirect member of Maria sales exec role group,plus Bob's East sales rep role group. And that's it for this lecture. This is a summary of the four access grants and the table used for each. First of all, we have the explicit grants, which are used when records are shared directly to users or groups, and they are granted by creating records and the object share table. A second, we have the group membership grants that are used when a user group Q role or territory is a member of a group that has explicit access to the record, and they are granted by creating records and the group maintenance tables. And then we have the inherited grants that are used when a user group or territory inherits access through a role or territory hierarchy or as a member of a group that inherits access through a group hierarchy. And they are granted by creating records and group maintenance tables. And finally, we have the implicit grants thatare used when non configurable record sharing behaviorsbuilt into salesforce, sales service and portal applicationsgrant access to certain parent and charge records,and they are granted by creating records andthe objects share stables. And finally, as usual, thanks for watching.

5. 1.3- Account, Opportunity and Case Teams

This is Section One, Declarative Sharing, and this lecture is about team sharing. The topics of this lecture are accountteam opportunities, team roles, access level, default teams, mastery, assigned teams, and case team. As we have seen before, Teams is a way to open up record access for accounts, opportunities, and cases. Record owners can use teams to allow other users to access their records. You can look at team sharing as something in between manual sharing and sharing rules. It's not as automated as sharing rules, but at the same time it's not as manual as sharing. So a team is just a group of users that work together on an account, on a sales opportunity, or on a case. The record owner adds team members and specifies the level of access that each one of these team members has to the record, so that some team members can have read-only access and others can have both read and write access. The record holder can also specify a role for each one of the team members. This is something like a sales engineer or a support specialist, and so on. Account, Opportunity, and Case configuration and setup are all possible. To do so, you have to go to the setup menu, and then you have to search for Team. And there you will find the three options. account team, opportunity team, and case team. These are the steps to enable Account Team Sharing. First of all, click on Enable Account Teams, and then click on the Account Teams enabled checkbox. These are again on the set-up menu once we search for the team. And then we found the Account Team, once enabled, added to the account-related lists and to the user-related lists by checking the corresponding checkboxes. Next, you can define the different roles for Account and Opportunity Team members under the Team Role link. And finally, note that account and opportunity team roles are the same. There's no way to differentiate between these two. So if we define Account Team roles, this will be the same as the Opportunity Team roles. After enabling Account Team Sharing, the related list will be added to the Account page because we checked the boxes for that. You can also add team members who will have access to the account record there. Also, the access level is specified here. The default team can also be added by clicking on the Add Default Team button. We will talk later about the default team. These are the steps to enable Opportunity Team sharing. First of all, we have to click on the "enable team selling" checkbox. Once enabled, we must check the corresponding check boxes to add it to the Opportunity layout related lists and the user related lists. Next, you can define the different roles for Account and Opportunity Team members. This is exactly the same as what we did on the Account Team. And as we mentioned, account and opportunity team roles are exactly the same. After enabling Opportunity Team sharing, the related list will be added to the Opportunity page layout. This is just because we checked the checkboxes, and there you can add team members that will get access to the Opportunity record. Also, the access level can be specified here. It can be either read or it can be write. The default team can also be added by clicking on Add Default Team. We'll see that in the next slide. With account and opportunity teams, there is an option called default account team and default opportunity team. The default Account and Opportunity Teams should include the users that normally work with you. You can automatically add the Default Opportunity and Account Teams to opportunities and accounts that you create or that are transferred to you. So this option allows you to specify a predefined set of users as your team. This way, there is no need to select these users one by one when adding them to the account or opportunity. A single click will only be needed. You can set your default opportunity for account-team members in settings and advanced user settings. Mossy-assigned teams are a feature that becomes available once Account all Opportunity Teams is enabled. What is this feature? Well, this feature, as the name suggests, can add a single user, a team member, to many accounts and opportunities at once. So instead of going to each one of the accounts or opportunities and adding this user to each one of these records, we use this feature to add the user as a team member to many records at once. This is the same for removing a user from many records and for replacing a user with another on many records. So you can use this feature as a way to mass add, mass delete, or mass add users on Teams. And this feature is only available for accounts and opportunities. It's not available for the Case Team. Now let's go to Salesforce, and let me show you the Account and Opportunity Teams in action. So I will go to my set-up menu. As you can see, I can search for the team on the top, and then I can see that I have three options. I have account teams, I have opportunity teams, and I have case teams. Let's start with the account team. So to enable it, you have to click on this link. So we first clicked on account teams, and then we clicked on enable account teams. And then we have to check this checkbox. Now this is the option that will tell Salesforce to add the Account Team to the Account page layout as a related list and on the user record. Now this is done. What we have to do now is specify the roles of the account team and the opportunity team because, as we mentioned, these are the same. So we have to click on "Team Roles." As you can see, we have a list of roles we can create, a new role, we can reorder these roles, we can replace them, and so on. Now let's go to the Opportunity Team. So we have to go to opportunity team settings and then check the enable team selling checkbox, click on save, and then choose to add the related list to the opportunity layout and to the user layout. And now I can disable it, but I don't want to do that now to set the rules. It's exactly the same thing. But now, as you can see, we have a link right on the Setup menu that we can use to set the team roles, which are exactly the same as the account roles. As a result, the roles of opportunity and account team are the same. Let's go to an account. Okay, so let's go to this account. Now, if I go to the related list, I can see that I have account teams added at the bottom. So what can I do? Now? I can either click on "Add team members" or I can click on "Add default team." This is not set yet. Once I set it, we can click on it. But now let's click on this one. So this is the list that we have. I can specify the user and the team role; this is one of the team roles that we have specified. And then we can specify the access level on the account, on the case, and then on the opportunity. Why? because case and opportunity are children of account. So let's first go to the list of users, and let's choose a user from a role that does not have access to that account. As you are aware, the OWD for accounts is read all, so anyone can read any account. So that's why we will use read and write access. Okay, so let's choose a user for this role. The SE team. We have Amy, and we have Jane. So I will go to Firefox, and then I will log in as Amy. This is Amy. If I click on accounts, I can see that Amy can see all of the accounts, but she cannot edit any one of them because the OWD is read only.So I will click on an account that is not owned by Amy. Let's say this account, and then if I click on Edit, you can see that this cannot happen. Okay? So the account that we picked is the global media account. It's owned by Rose, which means that Amy cannot edit this account. So if I click on this one and then edit, I cannot do that. So I will go back to my adminsalesforce, and then I will choose this user. The role would then be something like aM, and the account would be read/write. If I did that, what would happen? And then if I move to Firefox to view Amy's salesforce, and then if I refresh this page and click on Edit, You can see now that Amy can edit this account. I can do the same for the opportunities. So I can take advantage of an opportunity. Let's say this opportunity is owned by Sarah, and if I scroll down to the related list, on the related list, you can see that now we have an opportunity team added. I can do the same. I can either add my default team or I can choose users one by one. So let's go back to Amy, and let's go to opportunities. You can see that Amy cannot access any opportunity. Why? because the OWD opportunity is set to private Now, going back to my admin page, I will search for Amy. First of all, I need to select the role and then the user. We can start by reading only Returning to the Ames page refresh. You can see now that we will have access, but we cannot edit. Going back to the admin page, I can now edit the access level. I can make it read and write, going back to the Ames page refresh. Now I can edit. OK, now let's talk about the default team. The default team is set at this place. So I need to go to settings, and then you can see on the left side I have this menu. You can search for "advanced," and then you'll see that there's a rate list called "Default Account Team" and "Default Opportunity Team." You can see that I can specify this team, so I can specify the users on the left side, and let's say David. So Amy will be retried and David will also be retried, and that email will be used to click on Save. Now I have a default team. So my default opportunity team is these two users. Now what can I do if I go back to the opportunity record and then let me choose an opportunity that I do own? So let's say this one, and I will add my default team. There you can see that the owner's default opportunity was added, which means that David and Amy now should have access to this opportunity. Finally, what we'll talk about is the mass actions. Let me go to the setup menu, and I will search for team again. I now have these two options Masculia signs opportunity teams and mascassignaccount teams. The first step is to specify what I want to do. Do I want to add, remove, or edit? Let's go to add. And now we have to search for the accounts. Let me go to the account that I do own. Let's say this account exists, and let's say that I will select a field. Let's go to the type customers, then back to the Messiah sign, and then back to the type okay, click on Next. Now you can see that the result will return to me. Let's select them all, or we can select one of them. So in this case, let me select this one. Of course, in the case that I have so many, I can select all of them and I will click on "next." Okay, so what do I need to do? I need to add a role, read and write, and the user is Jim in this case, and the opportunity is red, correct? Account. I need to set the account to be red, right? And while we're at it, let's make it read-only. And this would be a private addition. So this is a way to add team members to accounts, not one by one. So I can select so many accounts, and then I can add team members to these accounts. Now if I go back to this account and refresh this page, you can see that this user has been added to the team of that account. I can do the same. I can edit the mass action option that I have; I can even delete. So if I go there, you can see that now I can choose to remove or replace. Now let's talk about the third team, which is the case team. A case team is a group of people that work together to solve cases. It can include different users with different roles like support agent, support manager, and so on. A case team role should be defined along with the access level. This differs from the account and opportunity team, where the role lacks access level. And when adding a user to a case as part of a team, the user's role should be defined, which defines the access level. Predefined case themes can be created. Each contains a list of users with the role, and finally, the case page layout should be modified and the case theme-related list should be added to it. To define the case theme role, we have to go to the setup menu, and then we have to search for case theme role. And as mentioned, for each role, you define the member role name and case access. It can be either private or read write.A predefined case scene can be set by the admin. This is used to quickly add people who you frequently work with on a case assignment. Rules can also be defined that add predefined teams to cases when they match a certain criteria. And on top of that, email errors can also be created to notify the case team members of any required change on a case. So let's say you want to email the whole case team when the status of the case reaches a certain threshold. This can be done using email alerts. To create predefined case themes, we have to go to the setup menu and search for predefined case themes. For predefined case themes, we have to specify the team name, team members, and role of each member, and the case access will be automatically set depending on the member's role. You can use a list of views to include cases where you are a team member. And on top of that, you can use a filter when building reports called "my team cases" to specify cases where you are a team member. The case team member related list should be manually added to the case page layout, and there is no automated way to do that. As we saw on the Account and Opportunity team, we had a checkbox, and this checkbox took care of adding this related list, but we don't have this on the Case Team. In this related list, you can add users as members of this case team, or you can also add a predefined team. A member can be a user, contact, or community user, and it should be assigned a role that was previously created with this access level. A team should be one that has had its members and their access level previously defined. Now let's go to Salesforce and let me show you the case theme in action. Okay, so as you can see, we talked about Account and Opportunity Teams. Now is the time to talk about case themes. So the first step is to check the roles, and then we can do the predefined case themes. As you can see, we don't have any roles defined. This is not the same as accounts and opportunity teams. Let's define this role. So this is a level two role, and in this case we have to give, read, write, and save. Now that we have this role, we can also add another role. Okay, so now we have two different roles. And as you saw, for each role, we define the access level. Now we have to go to the case object, and then we have to add the related list. So now we have the theme-related list added to the page layout of the case. Now let's go, and let's open a case. Okay, so let's go to case number one five.And if we go to the related list, you can see that now we have a case team added. If you recall, the ownership of cases is set to private, which means that any user can only see the cases that they own or the ones that they have access to through sharing. So let's go to this user, Amy, and we'll go to Cases, and we can see that she can access only one case, which is the case that we are on now. So let's pick another case and add Amy as a team member to it. We can add contacts or users, and then we can specify the role, which will define the access level. If we specify read, Amy will have read access in that case. So this is Amy, who is refreshing. And then you can see that she has read access to this case. She cannot edit this case. If I go back and edit this access, I need to delete it, and then I need to add it again. So we'll return to the case and then level two case theme, which means she can edit on top of leading Amy refresh, and she can now edit by returning to the admin page. Let's talk about the predefined team. Click on New. Let's call this a level three team. So I can specify user or contact, and then I can specify the user itself. So let's say that Henry and are the L three Ktheme and of course we can add a role for them. Now we have these two roles, we can callthis L two team instead of L three. In that case, this will be the whole team instead of each one of them. And as you can see, the access level is taken because we have specified the role. Now if I click on save, I have now defined a team, and then if I go to the case and let me refresh this page, now I can add this predefined team to the case by selecting "add team" instead of "add member," and then I will have the L-2 team. Yeah, this is the team, and then I can see the whole list, and then I can see the team being added. And this theme is composed of two users, which are the ones that we have added to the team before. And that's it for this lecture. In this lecture we have talked about another way to open up record access, which is called team sharing. Team sharing is applicable to three objects: account, opportunity, and case. The account team sharing enables record access by specifying access levels to the account, optionally to the account's opportunities, and optionally to the account's cases. The access level can be private, read-only, or read write.A predefined team can be added at once, and all the members of the team can be removed with one click. The opportunity team sharing is the exact same as the account team sharing, but it is applicable to opportunities. The opportunity team has the same feature as the account team. For both account and opportunity team sharing, the list of roles is the same. Default teams for both account and opportunity teams can be set for every user in his or her advanced settings. And as we said, only one click is needed to add all your default team members to an account or to an opportunity master. Assign can be used to reassign members in bulk to many records at once. This includes adding, removing, or replacing a user on many records at the same time. Finally, case team sharing follows the same concept as account and opportunity teams, but there are some small differences. The case team roles and their case access level should be predefined. Access level can be private, read-only, or read write.And when adding a member, a case team role should be specified, which specifies the level of the access users. Contacts and community users can all be members of a case team or a predefined case team. Likewise, the account and opportunity teams. Predefined case teams with a list of members and their roles can be created and assigned once to the case. And finally.

Hide