Search
  • Tony Nelson

Data Security of Salesforce / Force.com - Record Level

Updated: Feb 24


In the previous post, we discussed object-level security (especially profiles). Configuring access settings for the actual records is also important for securing data. Let’s explore what we can do, and how we can set up access control at the record level.


Types of Record Access

You set profiles to configure what type of things users can do to an object. In addition to that, you can configure which record users can view by record settings. Record access control is maintained by below.


– Organization-wide sharing defaults – Role hierarchy – Territory hierarchy – Sharing settings – Sharing by role hierarchy and public group – Criteria-based sharing rules – Account team (Opportunity team, Case team) – Apex-managed sharing


Organization-Wide Sharing Defaults

The first thing you need to consider in record access is “Organization-Wide Sharing Defaults”. You can set the basic condition of access level to records that belong to each object.



[Access Levels of Organization-Wide Sharing Defaults]

● Private … This setting is applied when there are records which users can see and cannot see.

● Public read-only … This setting allows users to see records but limits certain users to change records.

● Public read-write … This setting allows users to see and change all records


[Key Elements for Organization-Wide Sharing Defaults]

Access by External Users

When the portal license is used, not only internal users but external users can also access to objects. Limiting access to data is crucial.


You Can Only Add Access Permission with Sharing Rules


It is not possible to make the level even stricter than the access level specified by organization-wide sharing defaults. For example, you cannot add the “public read-write” condition to a certain roll if the given object is set as “private” by organization-wide sharing defaults.


Pay Special Attention to Master-Detail Relation Objects


It’s important to note that in the master-detail relationship, the master record settings are automatically inherited to the detail objects. Not only the fact that this relationship allows you to show aggregate sum, but also access level control should be considered.


When considering the best relation model between objects, the decision for whether you make it the master-detail relationship or the lookup relationship is tricky. A common mistake is a case where you choose the master-detail relationship as this relation includes the aggregated sum function. Let’s take a look at this example in the below sample scenario.


[Sample Scenario]

TerraSky Inc. is evaluating a system to receive orders from resellers on a portal site by using the portal license.

1. All users including resellers are able to see all products handled at TerraSky Inc.

2. TerraSky Inc. is the only one allowed to perform product maintenance.

3. You would like to display an icon corresponding to the order counts when you review a product.

4. It is not possible for resellers to see order information.


Given the scenario, suppose product masters and order transactions are managed in the system.


From the condition 1 in the scenario, you set product masters as “public – read-write” by the organization-wide sharing defaults.


Next, think about order transactions. If you decide to use “the order count” from condition 3 as an aggregated sum field, you choose a master-detail relationship with a product master. However, as a result, the “public read-only” setting will be inherited to order transactions so resellers could refer to order transactions. Therefore the best option would be to make a lookup relationship when you see product masters from order transactions and set sharing settings of the order transaction organization as “private”. Finally, implement the requirement for the product order counts for condition 3 by using an Apex trigger.


Role Hierarchy

How to define role hierarchy is crucial in determining record access control. Users in the upper role always have the same access to users below them by default (it is also possible to set the records hidden to upper users).


[Key Points for Designing Role Hierarchy]

Role hierarchy does not always have to be the same structure as the organization chart. In general, organization charts for corporations are complex. There are also possibilities for frequently changing the org structure. Because of those reasons what I suggest is to analyze the requirements for data access control first and simplify the hierarchy. As you know, one user can belong to only one role. However, some companies require employees to hold several posts. In that case, it would be much difficult to assign a role to a user if the role hierarchy were to be exactly the same as the corporate tree.


Territory Hierarchy

You can also control record access with the territory hierarchy, which is independent of the role hierarchy (please contact salesforce.com to enable). Territory hierarchy is described as a role hierarchy to sort out accounts. You can assign multiple conditions for accounts (region, country, industry type, # of employees, etc.) and multiple territories by manual. When you use the territory hierarchy, please note that security settings are applied to standard objects that are in the lookup relation with accounts and custom objects that are in the master-detail relation with accounts.


Role hierarchy in the Portal

There is a role hierarchy in the portal license for external users (note that not all portal licenses support role hierarchy). If you create a portal user for contacts, for example, a role hierarchy for the account which the contact person belongs to is automatically generated. The upper role of the account role will be the one where the account owner belongs. If you enable portal and create a portal user, special rules upon record sharing settings, such as “role, role & internal lower roles” and “role, internal & portal lower role” will be added. This is important for allowing only internal users to see data.


Sharing Rules

Sharing rules are the most important settings for controlling record access. You can arrange users in public groups, roles, or queues to grant sharing records by each object.


[Types of Sharing]

– Public Group – Role – Territory – Queue


You can set user’s access to a record based on the owner of an object or some specific conditions. You also set access levels (read-only / read and write) in sharing rules.


[Types of Record Sharing]

– Record ownership – Sharing based on specific conditions


[User Managed Sharing, or Manual Sharing]

User managed sharing allows the record owner to share the record individually. You can select the user to share the record.


Usually, auto setting is preferred for sharing as it requires less maintenance. User managed sharing allows you to make more detailed settings. However, keep in mind that those manual settings may become a burden in terms of operations. Also, it might create possible errors and it will become hard to understand which record is accessible to which users.


[Apex Managed Sharing]

With Apex managed sharing, you can develop sharing logics by using Apex code. Compared to sharing available for standard objects, it allows you to define more flexible settings. On the other hand, if anything changes it always requires technical developers to modify Apex code. In terms of maintenance and testing, Apex managed sharing may work against users.


Important Notes for Sharing Rules

[You Cannot Limit Access]

Sharing rules let you give additional users access to records. Therefore they cannot be stricter than your organization-wide default settings.


[Sharing Rules Affect Performance]

The complexity of role hierarchy, public rules and sharing rules as well as the number of rules do affect the performance, especially in mass-data processing. Therefore when you handle mass-data processing, you need to take performance into consideration then set sharing rules. In general, it is better to keep role hierarchy and sharing rules simple.


Summary

Here are the important points when you consider access control at the record level. – Consider the data model and decide the base access control type – Who is accessible to which records? Internal users? Or external users? – Is it possible to define sharing settings for standard objects? – Understand the difference of access control between portal license types

0 views

© 2019 TerraSky. All Rights Reserved, TerraSky, Inc.