Data Permissions Basics

Have more questions? Submit a request

This article will explain the basic permissions architecture behind Rethink. Permissions in Rethink is like an onion with many layers that are protected on the outside.  You must un-peel the onion, layer by layer, to expose its contents (in this case, data). You accomplish this in Rethink by explicitly granting read, edit, create, and delete access to data and objects in Rethink.  The following information can be found in Salesforce Trailhead.

Data Access Levels

You control which users have access to data, objects, fields, and individual records.

Access to object-level data is the simplest method form of control. By granting permissions at the object (tab) level, you can prevent certain users from creating, viewing, editing, or deleting records of that object. For example, you can use object permissions to ensure that brokers can view contacts and properties, but not edit or delete them.

You can restrict access to certain fields even if a user has access to the object. For example, you can make a specific field invisible to brokers, but visible to management and marketing. 

You can allow particular users to view an object, but then restrict the individual object records they are allowed to see. For example, an interviewer can view and edit her own reviews, but not the reviews of other interviewers. You can manage record-level access in these four ways.

  • Organization-wide defaults (Sharing Settings) 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 grant access to users higher up in the hierarchy to allow them access to not only their records, but records of users below them in the hierarchy as well.  For example, a manager might want to have access to her team's records. Role hierarchies do not have to match your organization chart. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.
  • Sharing rules are automatic exceptions to organization-wide defaults for particular groups of users, so they may access records they would not normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records, meaning they cannot be stricter than your organization-wide default settings.
  • Manual sharing allows owners of particular records to share them with other users. Although manual sharing isn’t automated like org-wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations.  An example would be when a recruiter is going on vacation and needs to temporarily assign ownership of a job application to someone else.

Please reach out to Product Support  at if you have any questions about setting up security for your org. 


Articles in this section

Was this article helpful?
0 out of 0 found this helpful