Salesforce.com is rapidly becoming the world leader of cloud technologies and CRM. They are achieving this status due to their rapid development and release schedule, continually delivering awesome new functionality 3x per year!

However, whenever a Security or Legal team hears the word “cloud,” they seem to tense up and start blinking rapidly, sputtering off all the things that could go wrong if sensitive data were released for hackers to capitalize on. This is a disorder I call ignoramous misinformilackofinsightus. Very serious. Yes, these would be valid concerns if there was not an industry-leading security model that protects everyone under Force.com’s cloud security blanket, as comforting as a soft cloud-like pillow for your data. Basically, Salesforce.com, Force.com, Data.com, Database.com, (please forgive me if I use these terms interchangeably, but they all reference that same platform) are all protected by an extremely complex, yet easy to administer and use security model. There are several components that give fine-grain control over:

Who can access data or application functions

can access data or application functions What data people can or can’t see

data people can or can’t see Where in the app can they access, or where they can access the app from

in the app can they access, or they can access the app from How users access data or application functions

users access data or application functions Wait, there’s no why!? Well, I’ll also tell you why

I’m going to attempt to live up to the title of this article by breaking down the cloud security blanket into terms anyone can understand. I’ll also include some tidbits of best use-cases. For more advanced ideas from a technical architect’s perspective, this beginner’s guide will be followed by a more advanced guides: Advanced Salesforce.com Data Security and Advanced Salesforce.com Application Security. A complete downloadable guide to designing enterprise security on the Force.com platform will also become available.

To give you some quick context for this guide, I am a Solution Architect with Bluewolf. We were salesforce.com’s first global consulting partner, so we take pride in our deep history and experience with the Force.com platform. As a Solution Architect, a large part of my job consists of big-picture strategy on how a Salesforce instance should be structured to optimize flexibility, scalability, and of course security. Let’s get started!

Force.com and Salesforce.com Security Model

In this section I will outline all of the security components available in Salesforce.com & Force.com, including definitions and proposed use.

In salesforce.com, there are two major types of security components:

Force.com Data Security:

Data security is comprised of components, rules, and objects that restrict access to data in Salesforce, e.g. who has access to certain accounts or contacts?

Force.com Application Security:

Application security consists of components, profiles, and permissions that determine which areas or functionality of the application users have access to, e.g. the ability to export data or manage contracts. Application Security will be covered in the next post.

Salesforce.com Data Security Components

This section will define each data security component available in the Force.com platform and provides definitions and high-level observations about how they are typically used, e.g. who gets access to certain accounts or contacts?

Salesforce.com User Record

User Record - Definition

A user record represents a single person or entity who is a user of salesforce.com. All other security components act on the user record to determine that user’s level of access to functionality and visibility of data.

User Record - Use

The user record is typically used for each person, employee, customer or partner accessing Salesforce.com. It can also be leveraged to associate users with territories, public groups, and other variables that may be utilized in other parts of the application. Another common use is assigning user records to applications that need to access Salesforce data such as data management tools, ETL integration middleware, etc. This is a great way to identify records that have been touched, imported or modified by an external application. There is also a hierarchical relationship-type that is unique to the user object. This is used to relate users to other users, which can then be leveraged in approval processes. e.g. An approval process requires VP approval, which is several roles above a user, so the direct relationship can be established and this hierarchical relationship field is leveraged in the approval process.

Salesforce.com Role Hierarchy

Role Hierarchy - Definition

The role hierarchy allows administrators to specify whether users have access to data owned by or shared with their subordinates in the hierarchy. The role hierarchy works in conjunction with Organization-Wide Defaults (OWDs) to determine the base level of access granted to records through the hierarchy.

Role Hierarchy - Use

The role hierarchy in Salesforce is used primarily for record access, reporting, forecasting, dashboard, and content purposes.

Roles effectively segregate users into logical groups, typically based on organizational structure, although this is not a requirement. It’s useful to follow the organizational/corporate structure all of the corporation’s employees who are using Salesforce. In this case, it’s logical to follow the corporate structure for approval processes and reporting.

Managers are able to filter down lists and reports to view only records they and members of their team own.

A common use is to group a global organization first by continental grouping, per corporate structure, then by job function. e.g. North America > Sales VP > Sales Manager > Sales Rep.

Salesforce.com Security Organization-Wide Defaults (OWDs)

OWD - Definition

OWDs can be established to dictate the visibility of records within each object in the database. The options for most objects include:

Private: Access to record is limited to record owner, users above owner in the role hierarchy, unless sharing rules or account teams grant access to additional users

Access to record is limited to record owner, users above owner in the role hierarchy, unless sharing rules or account teams grant access to additional users Public Read-Only: All users in the organization can access the records within the object, regardless of ownership and role hierarchy, but not edit the record unless ownership, role hierarchy, sharing rules or account teams grant edit access

All users in the organization can access the records within the object, regardless of ownership and role hierarchy, but not edit the record unless ownership, role hierarchy, sharing rules or account teams grant edit access Public Read/Write: All users in the organization can access and edit the records within the object, regardless of ownership and Role Hierarchy

All users in the organization can access and edit the records within the object, regardless of ownership and Role Hierarchy Controlled by Parent: Record access is dependent upon settings of its parent object. This is typically only possible where a certain type of relationship (master-detail) exists between the objects. This is also available on standard objects such as contacts, being controlled by accounts

OWD - Use

Organization-Wide Defaults are the cornerstone of the Salesforce security model. In most cases, a hybrid model is used, where some objects are public, and others are private. For customer-obsessed organizations, an open security model can be leveraged so any employee can engage your clients, regardless or their department. Empower employees by giving them access to the data they need to provide exceptional customer service. Don’t you just hate it when you get bounced around customer service departments as no-one can access your account history!?

Salesforce.com Public Groups

Public Groups - Definition

A public group represents a custom group of users defined by an administrator. Users can be added to a public group individually, or based on their assignment to a role (and its subordinates). Once an administrator has created a public group, other users in the organization can use it for security, content, and knowledge.

Public Group - Use

There are seemingly countless uses for public groups, the primary of which is to arrange bigger sets of users, into a group. So if you remember from our role hierarchy discussion, you could have several roles under the North American region, but what if you want a simple way to share all accounts in USA with all users in USA + a legal team? You could add both of these roles + subordinates to one group. This just makes things a little easier to manage. For example, if you have a new role that needs to be added to several sharing rules, rather than editing all sharing rules, you could add them to one group, and now that role inherits all sharing. Later, we’ll discuss what actually happens ‘under the security covers’ when sharing rules, roles, groups, and ownership changes. Pretty crazy stuff.

Salesforce.com Sharing Rule

Sharing Rule - Definition

Sharing rules allow administrators to automatically bypass organization-wide sharing settings. Sharing rules can open visibility to users in public groups, roles and territories, but are never used to restrict visibility. Sharing Rules can also be driven from specific criteria on the record that you are creating the rule on. The data used for criteria must reside on the object in the sharing rule.

Sharing Rule - Use

As you can tell from the name, sharing rules are used to share groups of records with groups of people. Since they are available in all standard and custom objects, you have a lot of flexibility here. They are really only used if the OWD for a certain object is anything other than public read/write. For example, you could open up read/write access to an operations team when the OWD dictates it’s read-only for everyone else (aside from record owners & those above them in the role hierarchy).

Salesforce.com Account and Opportunity Teams

Account and Opportunity Teams - Definition

An account/opportunity team is a group of users that work together on an account/opportunity. For example, your account team may include an executive sponsor, dedicated support representative, and project manager.

You can build an account team on each account that you own. When selecting an account team member, choose a role to indicate the role the person plays on the account. Also, depending on your sharing model, you can specify the level of access each account team member will have to the account and any contacts, opportunities, or cases associated with that account. So, you can give some team members read-only access and others read/write access.

Account and Opportunity Teams - Use

Per the definition, account and opportunity teams are primarily used for team selling and team account management. Users can also set up a default account/opportunity team. The default account/opportunity team should include the users that you normally work with on your accounts/opportunities. You have the option to automatically add your default account team to all of your accounts or a default opportunity team to all of your opportunities. A common use of default teams would be if the same group of users always work together on accounts or opportunities., e.g. the Sales Rep John Doe is always supported by Sales Engineer, John Smith.

In a custom list view, you can filter account/opportunity lists by the account/opportunity teams in which you are a member. When creating or editing a custom list view for accounts/opportunities, simply select the My Account/My Opportunities teams filter. In account/opportunity reports, you can filter accounts/opportunities by the account/opportunity teams in which you are a member.

Force.com Managed Sharing and Implicit Sharing

Force.com Managed Sharing and Implicit Sharing - Definition

Force.com managed sharing involves sharing access granted by Force.com based on record ownership, role hierarchy, and sharing rules. Effectively, this is what's happening ‘under the covers’ of our cloud security blanket and how Salesforce associates additional users with records, implied through role hierarchy, rules, etc. The sharing capabilities of the Force.com platform include a wide variety of features that administrators can use to explicitly grant access to data for individuals and groups. In addition to these more familiar functions, there are a number of sharing behaviors that are built into Salesforce applications. This kind of sharing is called implicit because it is 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.

Implicit sharing:

Is performed on accounts, contacts, cases and opportunities only

Grants access to a parent account—if you have access to a child contact, case or opportunity record of an account, you have implicit read only access on that account

Grants access to child entities—if you have access to a parent account, you may also have access to the associated contact, case or opportunity child entities. access is configured per child object within a role

Force.com Managed Sharing and Implicit Sharing - Use

So, there’s not really anything I can suggest here since this is not configurable. It is simply what Salesforce does in the background to ensure your users are seeing what you’d expect them to see when you assign users to a role or transfer ownership. However, since it happens whether you like it or not, it must be considered as performance could be jeopardised if mass ownership transfers are happening. Even if you’re only transferring 1000 records, millions of recalculations of data access can be happening behind the scenes.

Group Membership Operations and Sharing Recalculation

The Salesforce role hierarchy, public groups, and territories are closely connected to sharing rules and the special security features of Salesforce applications. Because of these relationships, seemingly simple changes to groups and group membership can sometimes involve substantial recalculations of users’ access rights. For example, when an administrator moves a user from one branch of the hierarchy to another, Salesforce performs all of the following actions to ensure that other users have correct access to data owned by that relocated user.

If the user:

Is the first member in his or her new role to own any data, Salesforce adds or removes access to the user’s data for people who are above the user’s new or old role in the hierarchy.

Has a new role with different settings for accessing contacts, cases, and opportunities, Salesforce does the following to reflect the change in settings: Adds shares to those child objects where the new settings are more permissive Removes existing shares where the new settings are more restrictive

Owns any accounts that have been enabled for either the customer or partner portals, Salesforce removes any child portal roles from the user’s original role and adds them as children to the user’s new role. Note: Salesforce also adjusts boss-implicit shares, which provide access in the hierarchy to records owned by or shared to portal users. Salesforce must perform these tasks for every portal-enabled account the user owns.

Salesforce also recalculates all sharing rules that include the user’s old or new role in the source group. It removes all of the user’s records from the scope of sharing rules where the old role is the source group and adds those records to the scope of rules where the new role is the source. Depending on the sharing rule settings for accounts, Salesforce might also add or remove shares to account child records.

Note: If the user owns portal accounts, and there are sharing rules that use portal roles as the source group, Salesforce might need to recalculate those rules. Some sharing rules may no longer be valid given the user’s new location in the hierarchy, in which case an administrator might need to modify or delete them. During the user’s move, the managers in the branch above the user’s old role lose access to all the data that the user owns, as well as to child records shared through the managers’ role settings. Managers in the branch above the user’s new role will gain access to the user’s accounts and to child records according to their own role settings. See: Designing Record Access for Enterprise Scale

Well, there we have it, all the components on the Force.com platform that dictate data security. However, this is only half the story. In my next post, The Definitive Guide to Salesforce Security: 102, I cover Force.com application security. Topics will include security profiles, permission sets, field-level security, etc.

A special thanks to Julie Harden and Brendan Conroy for their contributions to this guide.

Keep up with the evolution of Salesforce Security with our State of Salesforce Report: download it here.

Connect with an expert to learn more.