Skip to main content

Record Level Access in Salesforce

Data Access in Salesforce

To meet your company’s security needs, it’s important to understand what data access means to your users and to you.

Data Access: User’s Perspective

If you put yourself in your users’ shoes, you won’t necessarily know or care how you’re getting access to records, but you might want to understand what having access means within the context of your organization. The following graph can help users visualize the different kinds of access that can be configured in Salesforce.



For example, if a user has access to an account field, then they have access to both the account field and the account object itself. However, a specific account record, such as “Account A”, might not be accessible to that user due to additional access control applied via sharing rules or other tools.

Data Access: Architect’s Perspective

As an architect, you must both understand your user’s perspective and know how to grant users only the appropriate level of access to the data that they should be able to access.

From an architect’s perspective, data access in Salesforce falls into two main categories: object-level access, which includes field-level access, and record-level access.

Object-level access determines whether a user has access to a particular object, which fields they can see on that object, and which actions they can perform. You configure object level access on user profiles.

Restricting access

The “Read,” “Create,” “Edit,” and “Delete” object permissions determine which actions a user can perform on any of the object's records to which they have access. Field-Level Security allows you to prevent certain users from seeing sensitive or confidential information contained in records they can see.

Opening up access

The “View All” and “Modify All” object permissions give users access to all of an object’s records, regardless of record-level access settings.

Record-level access (called “Sharing” in Salesforce) determines which records a user can see for a particular object, using the following tools:

  • Organization-wide defaults
  • Role hierarchy
  • Territory hierarchy
  • Sharing rules
  • Teams
  • Manual sharing
  • Programmatic sharing

Because you have so many options for managing record-level access — and because some of these options are affected by organizational dependencies — determining which records users can access can quickly become complicated. Additionally, you might also be changing your sharing configuration frequently in response to new business requirements. This can trigger record access changes that ripple through your organization. These changes have an even greater impact in very large organizations, where it can take some time to
recalculate access for a large number of users, and adjust the tables that record their access rights. For these reasons, it’s important to understand how Salesforce calculates and grants access at the database level.

Record Access Calculation

Every time a user attempts to open a record, run a report, access a list view, or search for data using the user interface or API, Salesforce checks the configuration of its record access features to determine which records the user can access. These configurations can be elaborate, especially in large organizations with hundreds of hierarchy nodes, thousands of sharing rules, millions of data rows, and portals for customers and business partners. Processing such dissimilar data and complex relationships would require far more time than
the 300-millisecond Salesforce benchmark for rendering pages.

Rather than applying every sharing rule, traversing all hierarchies, and analyzing record access inheritance in real time, Salesforce calculates record access data only when configuration changes occur. The calculated results persist in a way that facilitates rapid scanning and minimizes the number of database table joins necessary to determine record access at run time.

Access Grants

When an object has its organization-wide default set to Private or Public Read Only, Salesforce uses access grants to define how much access a user or group has to that object’s records. Each access grant gives a specific user or group access to a specific record. It also records the type of sharing tool — sharing rule, team, etc. — used to provide that access. Salesforce uses four types of access grants: explicit grants, group membership grants, inherited grants, and implicit grants.

Explicit Grants

Salesforce uses explicit grants when records are shared directly to users or groups. Specifically, Salesforce uses explicit grants when:

  • A user or a queue becomes the owner of a record.
  • A sharing rule shares the record to a personal or public group, a queue, a role, or a territory.
  • An assignment rule shares the record to a user or a queue.
  • A territory assignment rule shares the record to a territory.
  • A user manually shares the record to a user, a personal or public group, a queue, a role, or a territory.
  • A user becomes part of a team for an account, opportunity, or case.
  • A programmatic customization shares the record to a user, a personal or public group, a queue, a role, or a territory.

Note: If your organization doesn’t have an efficient sharing architecture, it might encounter performance problems when you use automated processes that generate a very large number of explicit grants, such as major sales realignments.

Group Membership Grants

Grants that occur when a user, personal or public group, queue, role, or territory is a member of a group that has explicit access to the record. For example, if a sharing rule explicitly grants the Strategy group access to the Acme record, and Bob is a member of the Strategy group, Bob’s membership in the Strategy group grants him access to the Acme record.

Inherited Grants

Grants that occur when a user, personal or public group, queue, role, or territory inherits access through a role or territory hierarchy, or is a member of a group that inherits access through a group hierarchy.

Implicit Grants

Grants that occur when non-configurable record-sharing behaviors built into Salesforce Sales, Service, and Portal applications grant access to certain parent and child records. For example, with this default logic, sometimes referred to as built-in sharing, users can view a parent account record if they have access to its child opportunity, case, or contact record. If those users have access to a parent account record, they can also access its child opportunity, case, and contact records.


Comments

Post a Comment

Popular posts from this blog

.NET Core: Session Wrapper Design Pattern For ASP.NET Core

Here, we'll learn about Session Wrapper design pattern to ease the access of Session. We'll make our access of session "Typed". Also, we may apply any validation or constraint in this wrapper class. Step 1 - Create a Session Manager class   In this example, we are going to store two items in Session (i.e. ID & LoginName). We are injecting IHttpContextAccessor so that we can access the Session variable.  We are creating properties which are actually accessing Session variable and returning the data or writing the data to Session. We have added one helping property "IsLoggedIn" which is using other properties to make a decision. We may have more such helping/wrapper properties. using Microsoft.AspNetCore.Http; public class SessionManager       {           private readonly ISession _session;           private const String ID_KEY = "_ID";           private const String LOGIN_KEY = "_LoginName";           publ
Post a Comment
Read more

Facade Design Pattern

Facade Intent Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Motivation Structuring a system into subsystems helps reduce complexity. A common design goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a  facade  object that provides a single, simplified interface to the more general facilities of a subsystem. Consider for example a programming environment that gives applications access to its compiler subsystem. This subsystem contains classes such as Scanner, Parser, ProgramNode, BytecodeStream, and ProgramNodeBuilder that implement the compiler. Some specialized applications might need to access these classes directly. But most clients of a compiler generally don't care about details like parsing and code generation; they merely want to compile some code. For them, the powerful but low-level
Post a Comment
Read more

Tabla - An Indian classical instrument for Rythm

Tabla Indian music has fascinated the West for many years. The tabla in particular has attracted the attention of a number of American and European percussionists. It has been used in popular music as early as the 60's and is heard in the popular media even today. However, many percussionists shy away from this instrument. The reasons for not "getting into it" are varied. Sometimes it is the lack of instruments; sometimes lack of teachers; sometimes it is the belief that tabla is just too difficult. These are legitimate concerns but they are not insurmountable obstacles. This article will address the concerns of a musician just wishing to get started in tabla. We will discuss the theory of Indian music, how to purchase tabla, the basic technique, and compositional theory. All of this information should make the job of getting started much easier. We should first familiarize ourselves with the extensive theory of Indian music. Indian music is one of the oldest musical trad
Post a Comment
Read more

How to make a Method Thread Safe?

In multi-threaded applications where multiple threads make calls to the methods of a single object, it is necessary that those calls be synchronized. If code is not synchronized, then one thread might interrupt another thread and the object could be left in an invalid state. A class whose members are protected from such interruptions is called thread-safe. Although, there is no rule that makes the code thread safe, the only thing you can do is make sure that your code will work no matter how many times is it being actively executed, each thread can be interrupted at any point, with each thread being in its own state/location , and this for each function (static or otherwise) that is accessing common objects. If a method (instance or static) only references variables scoped within that method then it is thread safe because each thread has its own stack: In this instance, multiple threads could call ThreadSafeMethod concurrently without issue. public class Thing { publ
Post a Comment
Read more

Create VHD using DISKPART

Create Virtual Harddisk Using DISKPART Open the   Elevated Command Prompt   with Administrator Privileges and type the following commands: DISKPART CREATE VDISK FILE="c:\win7\win7.vhd" MAXIMUM=20000 SELECT VDISK FILE="c:\win7\win7.vhd" ATTACH VDISK CREATE PARTITION PRIMARY ASSIGN LETTER=X FORMAT QUICK LABEL=Windows7 EXIT This will create the  VHD  file of primary partition. You will see the newly attached disk in Disk Management with Drive Letter X: Attaching and Detaching VHD in  Windows 7 Right Click  on My Computer and Click ' Manage ' that will open up  Computer Management , in that click on  Disk Management . Just like previous part. Then Right Click on Disk Management and select  'Attach VHD'.  This will open new windows  'Attach Virtual Hard Disk ' Click on  OK  and that will attach the existing Virtual Hard Disk. Now, if you don't want to make write anything on the VHD, we
Post a Comment
Read more