Record Ownership

Question 1

Full Access

Answer 1

View, edit, transfer ownership, change record type, delete, share

Question 2

System Permissions are controlled by:

Answer 2

Profiles, permission sets, permission group sets

Question 3

Types of Admin:

Answer 3

System, delegated, custom
(admins get access to all records by default)

Question 4

Record Permission/Restriction Hierarchy

Answer 4

System Permission -> Record Ownership -> Organisation Wide Defaults -> Roles -> Sharing Rules (incl. sharing rules, teams, and manual sharing)

Question 5

Object Permissions

Answer 5

Read, Create, Edit, Delete, View All, Modify All, View Setup, Edit Setup, Delete Setup

Question 6

Record Owner

Answer 6

Given the appropriate profile/permission set permissions, the User owning a record can view, edit, share, transfer, and delete records that they own.

Permissions may include Modify All and View All on any Object.

Question 7

Queue

Answer 7

Queues can act as an “Owner” of records.

Queue members are comprised of any combination of public groups,
roles, roles + subordinates, and users.

A list view is automatically created when a queue is created.

Queue can be used with leads, cases, tasks, or custom objects.

Question 8

Access to Records that I own:

Answer 8

VESTD (ownership privileges):
- View, Edit, Share, Transfer, Delete + Change a record type
- Depends on CRED (if ‘D’ removed from CRED, ‘D’ removed from VESTD as well)

Question 9

Access to Records that I don’t own:

Answer 9

Through:
- Organisation Wide Defaults
- Role Hierarchy
- Sharing Rules
- Manual Sharing (manual + team)

Question 10

Organisation Wide Default Access Levels:

Answer 10

Private, Public Read Only, Public Read / Write, Public Read / Write / Transfer (Leads and Cases)

Question 11

OWD Private Access:

Answer 11

Search for/report on owned records only.

Question 12

OWD Public Read Only Access:

Answer 12

Search for/report on any records
+ Add related records.

Question 13

OWD Public Read/Write Access:

Answer 13

Search for/report on any records
+ Add related records
+ Edit details of records

Question 14

OWD Public Read/Write/Transfer Access:

Answer 14

Search for/report on any records
+ Add related records
+ Edit details of records
+ Change ownership of a record
- Used when wanting to transfer the lead to somebody more experienced

Question 15

Organisation Wide Defaults are also used to:

Answer 15

Implement your Data Access Model
- except setting default level of access users have to records they don’t own
& imposing access restrictions

Question 16

OWD’s Data Access Models are used to:

Answer 16

Set the default level of access users have to records they do not own, for each object

Question 17

Data Access Model Types:

Answer 17

Private, Hybrid, Public
+ they cannot be changed on the DETAIL in a tight relationship, because it’s controlled by a parent

Question 18

Default Internal Access is set to:

Answer 18

As “open” as possible: Public Read/Write OR Public Read/Write Transfer (for Cases & Leads)

Question 19

Default External Access is set to:

Answer 19

As “closed” as possible: Private

Question 20

Private Data Access Model

Answer 20

Users can only access records that they own
+ cannot see records owned by other users in reports and search results.

Question 21

Hybrid Data Access Model

Answer 21

Users can access records that they own
+ only the records of other users that are necessary for their job function.

Question 22

Public Data Access Model

Answer 22

• No restrictions on record access.
• Users can view and edit any record that their profile permissions allow.
• Default Data Access model (Read / Write)

Question 23

Role Hierarchy

Answer 23

Open access VERTICALLY to anyone denied access by the OWDs in private or hybrid data models

• Users in higher roles inherit the special ownership privileges (full access) on all records owned by users in roles below them
• Custom object records do not have to be inherited
• Role hierarchy makes you a co-OWNER (2nd way how to become one, 1st way – VESTD)
• Based on CREDs

Question 24

Roll-up

Answer 24

Whatever my subordinates can do, I can do as well

Question 25

Roles are used to:

Answer 25

Share data and other components + they are used to create public groups + they are used in automation + they are used to share reports, dashboard, templates

Question 26

Roles and Organisation Hierarchy

Answer 26

Roles do NOT have to reflect organisational hierarchy Roles reflect the organisational chart BUT role hierarchy != organizational chart

Question 27

Implicit Account Access (role hierarchy)

Answer 27

Regardless of role, a user who owns a child record of an account (opportunity, case, or contact) gains READ access on that account if they have the right account object permissions + you cannot overwrite this rule

Question 28

Associated Record Access (role hierarchy)

Answer 28

Defines the level of access an account owner will have to the related records owned by users who are not their subordinates + Options available for Contact, Opportunity and Case access are dependent on the OWD set for each object: No Access, View, or Edit

Question 29

Floating Users

Answer 29

Users who don't have a specified role + If nobody is above a user, nobody will be able to delete records of that user

Question 30

Sharing Rules are:

Answer 30

- Exceptions to organisation wide defaults - Irrelevant to public data access models - Designed to give access in one direction only + they grant additional record access to groups of users on an object-to-object basis

Question 31

Sharing Rules are:

Answer 31

- Exceptions to organisation wide defaults - Irrelevant to public data access models - Designed to give access in one direction only + they grant additional record access to groups of users on an object-to-object basis + non-vertical access

Question 32

Sharing Rules types:

Answer 32

Criteria-based & Ownership-based - Criteria can be Field, Operator, Value

Question 33

Sharing Rules: from which users?

Answer 33

- Public Groups - Roles - Roles and Subordinates - Queues (cases only) - Usernames not possible

Question 34

Sharing Rules: to which users?

Answer 34

- Public Groups - Roles - Roles and Subordinates

Question 35

Sharing Rules: level of access

Answer 35

- Read Only - Read / Write

Question 36

Public Groups

Answer 36

An administrator-defined grouping of users used to simplify the creation of sharing involving many users. + Lateral, horizontal levels in org (sales rep from our and newly acquired company) + Can contain individual users, roles, roles and subordinates, and other public groups

Question 37

Manager Groups

Answer 37

Are used to share records up or down the management chain using sharing rules or manual sharing + They can be used to share records with your management chain, instead of all managers in the same role based on the role hierarchy + They can be used wherever other groups are used, such as in a manual share or sharing rule