Salesforce Basic Trial 3 (Data Security) Flashcards
Explain the importance of giving the right people access to the right data
Balance security and convenience, reduce the risk of stolen or misused data, and still make sure all users can easily get the data they need.
Explain the four levels at which you can control data access
- Organization: For your whole org, you can maintain a list of authorized users, set password policies, and limit logins to certain hours and locations.
- Objects: By setting permissions on a particular type of object, you can prevent a group of users from creating, viewing, editing, or deleting any records of that object. E.g. You can use object permissions to ensure that interviewers can view positions and job applications but not edit or delete them.
- Fields: You can restrict access to certain fields, even if a user has access to the object. For example, you can make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.
- Records: You can allow particular users to view an object, but then restrict the individual object records they’re allowed to see. For example, an interviewer can see and edit her own reviews, but not the reviews of other interviewers.
Explain how to manage record-level access (4 ways)
- Organization-wide defaults specify the default level of access users have to each others’ records. You use org-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.
- Role hierarchies give access for users higher in the hierarchy to all records owned by users below them in the hierarchy; should be given based on access need not necessarily organisational hierarchy
- Sharing rules are automatic exceptions to organization-wide defaults for particular groups of users, so they can get to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records.
- Manual sharing allows owners of particular records to share them with other users; ideal for temporal assigning of ownership
Explain the purpose of audit system use
- Detect potential abuse by;
- Record modification fields (i.e., who created and who last modified the record)
- Login history
- Field history tracking
- Setup Audit Trail (logs when modifications are made to your org’s configuration)
Can you delete a user?
- No, but you can deactivate an account so a user can’t log in.
- Deactivated users lose access to all records. (That includes records that are shared with them individually and records shared with them as team members.) However, you can still transfer this data to other users and view the names on the Users page.
Explain how to manage object permissions
- You can set object permissions with profiles or permission sets. Each user is assigned one profile. Users can be assigned one or more permission sets.
- A user’s profile determines the objects they can access and the things they can do with any object record (such as create, read, edit, or delete).
- Permission sets grant additional permissions and access settings to a user.
Explain the difference between page layouts and field-level security controls
Unlike page layouts, which only control the visibility of fields on detail and edit pages, field-level security controls the visibility of fields in any part of the app, including related lists, list views, reports, and search results.
Explain how record level permissions differ from object-level and field-level
The permissions on a record are always evaluated according to a combination of object-level, field-level, and record-level permissions.
When object-level permissions conflict with record-level permissions, the most restrictive settings win.
Explain the four ways of controlling record-level access
[in increasing access]
- Org wide defaults specify the default level of access users have to each other’s records
- Role hierarchies ensure managers have access to the same records as their subordinates. Each role in the hierarchy represents a level of data access that a user or group of users needs.
- Sharing rules are automatic exceptions to org-wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see (cannot be used to restrict access)
- Manual sharing lets record owners give read and edit permissions to users who might not have access to the record any other way.
*always start with the most restrictive level of access
Explain the four sharing models
- Private: Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records.
- Public Read Only: All users can view and report on records, but only the owner, and users above that role in the hierarchy, can edit them.
- Public Read/Write: All users can view, edit, and report on all records.
- Controlled by Parent:
A user can view, edit, or delete a record if she can perform that same action on the object it belongs to.
Explain the “Grant Access Using Hierarchies” option
- If the Grant Access Using Hierarchies option is disabled for a custom object, only the record owner and users granted access by the org-wide defaults receive access to the object’s records.
- Else, users at any given role level can view, edit, and report on all data owned by or shared with users below them in the role hierarchy.
- By default, the Grant Access Using Hierarchies option is enabled for all objects. It can only be changed for custom objects.
Explain when the sharing rules is most applicable for
- Sharing rules work best when they’re defined for a particular group of users that you can determine or predict in advance, rather than a set of users that frequently changes