Salesforce Sharing and Visibility

Public Group

A public group (not Chatter group) is a collection of individual users, roles, territories, and so on, that all have a function in common. Public group can consist of: Users • Customer Portal Users • Partner Users • Roles • Roles and Internal Subordinates • Roles, Internal and Portal Subordinates • Portal Roles • Portal Roles and Subordinates • Territories • Territories and Subordinates • Other public groups (nesting)

Consideration: what If a single user owns more than 10,000 records

If a single user owns more than 10,000 records, as a best practice: - The user record of the owner should not hold a role in the role hierarchy. -If the owner's user record must hold a role, the role should be at the top of the hierarchy in its own branch of the role hierarchy.

Use Cases for Role Hierarchies

Management access - the ability for managers to be able to see and do whatever their subordinates can see and do. Management reporting - the ability for reporting to roll up in a hierarchical fashion so that anyone higher in the hierarchy sees more data than those below them. Segregation between organizational branches - different business units don't need to see each other's data; having a hierarchy in which you can define separate branches allows you to segregate visibility within business units, while still rolling visibility up to the executive levels above those units. Segregation within a role - in many organizations/applications, people who all play the same role should not necessarily see each other's data. Having hierarchical roles allows you to define a "leaf" node in which all data is essentially private, and still roll that data up to a parent role that can see all.

Queues

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

View All and Modify All object level permissions ignore sharing rules, True or False

True

Record access scope for users in the role hierarchy

Users higher in a hierarchy (role or territory) inherit the same data access as their subordinates for standard objects. Managers gain as much access as their subordinates. If the subordinate has read-only access, so will the manager. This access applies to records owned by users, as well as records shared with them.

Role Hierarchy

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

Record Ownership and Queues

- Every record must be owned by a single user or a queue - The owner has access to the record, based on the Object Settings for the owner's profile. For example, if the owner's profile has Create and Read permission on an object, but not Edit or Delete permission, the owner can create a record for the object and see the new record. However, the owner won't be able to edit or delete the record.

Org Wide Defaults

- Organization-wide sharing settings specify the default level of access users have to each others' records. - You use organization-wide sharing settings to lock down your data to the most restrictive level, - and then use the other record-level security and sharing tools to selectively give access to other users.

Public Group Use Case

- When you need to provide access to an arbitrary group of people, you create a public group to collect them, and then use other sharing tools to give the group the necessary access. Group membership alone doesn't provide data access. - Groups can also be nested inside each other, therefore, allowing a nested group to gain the same access as the group in which it is contained. This allows the creation of smaller, ad-hoc hierarchies that don't necessarily interact with the role or territory hierarchies. If Group A is a member of Group B, then the members of Group A will have access to data shared to Group B at the same access level as the members of Group B. Groups also have the ability to protect data shared in the group from being made accessible to people in the role hierarchy above the group members. This (and dealing with the access of record owners and their management hierarchy) allows the creation of groups in which very highly confidential information can be shared—the data will be accessible ONLY to group members, and nobody else in the organization. This is accomplished by using the Grant Access Using Hierarchies setting.