Salesforce Data Security Model & Sharing

The Salesforce Platform

• Salesforce is a technology company that built and maintains the force.com platform-as-a-service (Paas)

• Revenova is just one of the 3,400+ applications built on this force.com platform.

• We leverage many of the built-in capabilities that are native to the force.com platform to manage:

  • Profile and permission settings (Preventing/Granting access to certain abilities within the app)

    • Data sharing model (Sharing data across groups and with management)

Important Terminology

• Database: “giant spreadsheet”

• Object: tabs in the “giant spreadsheet” that store particular kinds of information

  • Standard objects: Account, Contact

  • Custom objects: Loads, Customer/Carrier Quotes

• Field: columns in the object database table.

• Record: rows in the object database table. Records are the actual data associated with an object.

• Org: short-hand term for organization

Salesforce has tools that allow a System admin to control security at an Object-level, Field-level, and Record-level

Salesforce Sharing Methods

• Profiles

  • A profile is a group/collection of settings and permissions that define what a user can do in salesforce. A profile controls “Object permissions, Field permissions, User permissions, Tab settings, App settings, Apex class access, Visualforce page access, Page layouts, Record Types, Login hours & Login IP ranges.

• Permission Sets

  • Very similar to profile. The main difference between these two is that user can have only one profile and can have multiple permission sets at time. In such case, most permissive setting applies.

• Organization Wide Defaults

  • Organization-wide sharing defaults set the baseline access for your records. Options include Private, Public Read Only, Public Read/Write and Controlled By Parent

• Role Hierarchy

  • Represents a level of data access that a user or group of users needs. Users assigned to roles near the top of the hierarchy get to access the data of all the users who fall directly below them in the hierarchy.

• Sharing rules

  • Automatic exceptions to your organization-wide sharing settings for defined sets of users. Standard way to open up record access.

• Sharing Sets

  • Grants high-volume users access to any record associated with an account or contact that matches the

• Sharing Groups

  • Allow you to share records owned by high-volume community users with internal and external users in your communities.

• Partner Super Users

  • Partner Super Users have access to data owned by their peers (same role). Partner super user access applies only to cases, leads, custom objects, and opportunities.

• Public Groups

  • A group consists of a set of users. A group can contain individual users, other groups, or the users in a particular role or territory. It can also contain the users in a particular role or territory plus all the users below that role or territory in the hierarchy.

• Queues

  • Queues help you prioritize, distribute, and assign records to teams who share workloads. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue. Use queues to route lead, order, case, and custom object records to a group

• Teams

  • For accounts, opportunities, and cases, record owners can use teams to allow other users access to their records. A team is a group of users that work together on an account, sales opportunity, or case. Record owners can build a team for each record that they own. The record owner adds team members and specifies the level of access each team member has to the record, so that some team members can have read-only access and others can have read/write access. The record owner can also specify a role for each team member, such as “Executive Sponsor.” In account teams, team members also have access to any contacts, opportunities, and cases associated with an account.

• Territory Management

  • An account sharing system that grants access to accounts based on the characteristics of the accounts

• Implicit Sharing

  • Sharing not configured by administrators; it is defined and maintained by the system to support collaboration among members of sales teams, customer service representatives, and clients or customers. Includes Parent, Child, Portal and High Volume

• Manual Sharing

  • Sharing done directly by record owners by clicking the Share button

• Apex method sharing

  • Sharing generated through Apex by creating records in the Sharing objects
    

Two Key Concepts

Ability – do

1. Ability – What can a User do in the system?

   • e.g. Should User XYZ have the ability to edit Customer Invoices?

   • Should User ABC have the ability to see the Freight Plan Console tab?

   • Should User DEF have the ability to create new Reports?

   • Should User GHI have the ability to see the “Credit Limit” field on the Transportation Profile?

Access – see

2. Access – What data can a User see in the system?

   • e.g. Should User XYZ have access to Customer Invoices for Customer ABC?

   • Should User ABC have access to Loads for Customer XYZ?

   • Should User DEF have access to Reports created by User XYZ?

   • Should User GHI have access to Carrier Transportation Profiles?

Permissions

Salesforce data sharing lets you expose specific data sets to individuals and groups of users. Permission Sets, Permission Set Groups, and Profiles provide object-level and field-level security by controlling access. Record-level Sharing settings, user Roles, and Sharing Rules control the individual records that users can view and edit.

You can utilize the Revenova User Detail Upload Excel file to document and manage the various types of profiles and permission sets in your organization. First, determine the basic level of access that each Profile needs and then which users are assigned to each profile. Refer to this table as you set up your security model and update it as you allow or remove permissions.

User Permissions

User permissions and access settings specify what users can do within an organization. User permission settings are specified in Profiles and Permission Sets. To use them effectively, it’s essential to understand the differences between the two.

Profiles

Profiles control what users can do in your Salesforce ORG. This can be called CRED: Credit, Read, Edit, Delete. You may want some users in your org to read and edit Accounts, not delete them. CRED enables you to mix and match what a specific user can do within each object.

A profile is a collection of settings and permissions. Profiles are designed to group users into job functions, for example, ‘System Administrator’, ‘Operations Rep’, or ‘Carrier Rep’, but you can have profiles for anything that makes sense for your organization. Every user is assigned only 1 profile but can have multiple permission sets assigned.

• Each user has a single profile that controls what a user can do within an object, field-level security (which fields are visible or editable) page layouts, record types, and apps.

• A profile can be assigned to many users, but a user can have only one profile at a time.

• Profiles are used to provide minimal permissions for accessing the objects.

• Use Profiles to Restrict Access.

Object Permissions

An object is a collection of records, such as Accounts or Contacts. Object permissions specify the base-level access users have that allows them to Create, Read, Edit, and Delete records for each object. The combination of profiles and permission sets gives you a great deal of flexibility in specifying object-level access.

• Let you hide whole tabs and objects from users, so that they don’t even know that type of data exists.

• Either respect or override sharing rules and settings.
  
  

The “View All” and “Modify All permissions override all other sharing settings, so use caution when assigning them to any profile other than the System Administrator.

Field Permissions

Field permissions specify the access level for each field in an object. Field permissions control the visibility of fields in any part of the app, including related lists, list views, reports, and search results. To ensure that a user can’t access a particular field, use field permissions.

• No other settings provide as much protection for a field.

• Page layouts only control the visibility of fields on detail and edit pages.
  
  

Record-Level Security (Sharing)

After setting object and field-level access permissions, you can configure access settings for the actual records themselves. Record-level security lets you give users access to some object records, but not others. Every record is owned by a user or a queue. The owner has full access to the record. In a hierarchy, users higher in the hierarchy always have the same access to users below them in the hierarchy. This access applies to records owned by users and records shared with them.

To specify record-level security, set your organization-wide sharing settings, define a hierarchy, and create sharing rules.

Organization-Wide Sharing Settings

The first step in record-level security is to determine the organization-wide default (OWD) sharing settings for each object. Organization-wide sharing settings specify the default level of access users have to each other’s records. Your organization-wide default sharing settings give you a baseline level of access for each object and enable you to extend that level of access using hierarchies or sharing rules. Golden rule: the ‘org wide default’ should be set to the most restrictive level. Salesforce permissions work by opening access, not by locking them down. So, start with the strictest in mind.

You use organization-wide sharing settings to lock down your data to the most restrictive level.

Use record-level security and sharing tools to selectively give access to other users.

For example, users have object-level permissions to read and edit accounts, and the organization-wide sharing setting is Read-Only. By default, those users can read all account records, but can’t edit any unless they own the record or are granted other permissions (object level).

Role Hierarchy

After you specify organization-wide default sharing settings, the first way to give wider access to records is with a role hierarchy. Roles are designed to increase data visibility, to open access to Salesforce records. Like an organization chart, a role hierarchy represents a level of data access that a user or group of user’s needs. The role hierarchy ensures that users higher in the hierarchy can always access the same data as users who are at a lower level, regardless of the organization-wide default settings. Each role in the hierarchy can represent a level of data access that a user or group of users’ needs rather than matching your organization chart. Similarly, you can use a territory hierarchy to share access to records.

Although it’s easy to confuse Permission Sets and Profiles with Roles, they control two different things.

• Permission Sets and Profiles control a user’s object and field access permissions.

• Roles primarily control a user’s record-level access through role hierarchy and sharing rules.
  
  
  

Sharing Rules

Sharing rules represent the exceptions to your organization-wide default settings. Sharing Rules are used to extend the Role Hierarchy, so you are not restricted to the ‘top-down’ layout in the hierarchy. Sharing rules can enable you to open record visibility horizontally across the hierarchy. Use sharing rules to give these users access to records they don’t own or can’t normally see.

• You can use sharing rules to grant wider access to data.

• You can’t restrict access below your organization-wide default levels.

• To create sharing rules, your organization-wide defaults must be Public Read Only or Private.

• If multiple sharing rules give a user different level of access to a record, the user gets the most permissive access level.

• You can define up to 300 total sharing rules for each object.