Record Ownership Flashcards
Full Access
View, edit, transfer ownership, change record type, delete, share
System Permissions are controlled by:
Profiles, permission sets, permission group sets
Types of Admin:
System, delegated, custom
(admins get access to all records by default)
Record Permission/Restriction Hierarchy
System Permission -> Record Ownership -> Organisation Wide Defaults -> Roles -> Sharing Rules (incl. sharing rules, teams, and manual sharing)
Object Permissions
Read, Create, Edit, Delete, View All, Modify All, View Setup, Edit Setup, Delete Setup
Record Owner
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.
Queue
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.
Access to Records that I own:
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)
Access to Records that I don’t own:
Through:
- Organisation Wide Defaults
- Role Hierarchy
- Sharing Rules
- Manual Sharing (manual + team)
Organisation Wide Default Access Levels:
Private, Public Read Only, Public Read / Write, Public Read / Write / Transfer (Leads and Cases)
OWD Private Access:
Search for/report on owned records only.
OWD Public Read Only Access:
Search for/report on any records
+ Add related records.
OWD Public Read/Write Access:
Search for/report on any records
+ Add related records
+ Edit details of records
OWD Public Read/Write/Transfer Access:
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
Organisation Wide Defaults are also used to:
Implement your Data Access Model
- except setting default level of access users have to records they don’t own
& imposing access restrictions
OWD’s Data Access Models are used to:
Set the default level of access users have to records they do not own, for each object
Data Access Model Types:
Private, Hybrid, Public
+ they cannot be changed on the DETAIL in a tight relationship, because it’s controlled by a parent
Default Internal Access is set to:
As “open” as possible: Public Read/Write OR Public Read/Write Transfer (for Cases & Leads)
Default External Access is set to:
As “closed” as possible: Private
Private Data Access Model
Users can only access records that they own
+ cannot see records owned by other users in reports and search results.
Hybrid Data Access Model
Users can access records that they own
+ only the records of other users that are necessary for their job function.
Public Data Access Model
- No restrictions on record access.
- Users can view and edit any record that their profile permissions allow.
- Default Data Access model (Read / Write)
Role Hierarchy
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
Roll-up
Whatever my subordinates can do, I can do as well
Roles are used to:
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
Roles and Organisation Hierarchy
Roles do NOT have to reflect organisational hierarchy
Roles reflect the organisational chart BUT role hierarchy != organizational chart
Implicit Account Access (role hierarchy)
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
Associated Record Access (role hierarchy)
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
Floating Users
Users who don’t have a specified role
+ If nobody is above a user, nobody will be able to delete records of that user
Sharing Rules are:
- 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
Sharing Rules are:
- 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
Sharing Rules types:
Criteria-based & Ownership-based
- Criteria can be Field, Operator, Value
Sharing Rules: from which users?
- Public Groups
- Roles
- Roles and Subordinates
- Queues (cases only)
- Usernames not possible
Sharing Rules: to which users?
- Public Groups
- Roles
- Roles and Subordinates
Sharing Rules: level of access
- Read Only
- Read / Write
Public Groups
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
Manager Groups
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
