Salesforce.

com Security Model Implementation Best Practices and Considerations

May 22, 2011

Copyright 2011 Clear Task, Inc.

Executive Summary
While the focus of many Salesforce implementations both the initial set-up and ongoing evolution is on delivering the features needed to support a companys business processes, varying degrees of attention are given to ensuring that the solution is delivered in a manner where users have access to a level of data and features appropriate to their job function. It has been Clear Tasks experience that a thorough consideration of an implementations security approach generally comes second to feature function considerations, and that companies tend to under-estimate this implementation aspect until one or more of the following occur: 1. Security Breach: An unintended security breach where users (regular Salesforce users, customer portal users, or partner portal users) access data not intended for them 2. Company Growth: The company grows to a size much larger than the original implementation model took account for, and now a tiered security model is needed to lock down certain data and features to users 3. Business Process Growth: The company implements additional business processes than the original implementation model made account for 4. Salesforce Maintenance Burden: When the number of profiles, sharing rules, page layouts, and management of an expanding role hierarchy starts to become an administrative burden it may be a sign that the security model is ready for a review and over-haul. This document presents a set of best practices and implementation considerations to help ensure that your implementation initial and ongoing maintenance will deliver the intended value to your business users, while also protecting the data assets and integrity of the system.

Copyright 2011 Clear Task, Inc.

Security Framework
While there is an array of Salesforce security configuration choices, many which are covered in this document, Clear Task likes to use the following framework to conceptualize the two main configuration categories that influence the extent to which a company can achieve a secure system meeting the functional needs of its users that also provides the appropriate level of data security.

What people see Default security (OWD) Role Hierarchy Sharing rules Object configuration Apps & Tabs Folder & list view access Reports & dashboards

What people can do Create/ read/ edit/ delete Key Profile Options: Export Reports API Access Lead Conversion Manage public reports/ folders/ documents etc. Install AppExchange apps

What people get to accomplish their jobs Appropriate data access Appropriate feature access Analysis to manage Limited to no admin rights

The document addresses the most important items covered in the framework along with best practices and considerations.

Copyright 2011 Clear Task, Inc.

Where To Get Started?

With such a large number of available configuration options many companies are not clear on where to start. Clear Task comes across many of the following type of questions and concerns. Should a private or a public sharing model be adopted? How many system administrators should there be? What is the right profile strategy? Should the role hierarchy match the organization chart? What is needed if partner or customer portal is being used? How is delegated administration used? How is the data protected if there are integrations to external systems? Clear Tasks position is that the answers to these questions are found through a business discovery exercise that reveals: The business objectives of the Salesforce implementation The business processes being supported The organizational relationship between the various user and groups While the scope of this document is beyond providing a complete business discovery questionnaire the following questions provide directional information on at least high-level security settings: What are the primary business objectives for implementing Salesforce? What Salesforce clouds are being implemented Sales, Service, Custom, Jigsaw, Heroku, etc? If Sales Cloud: o What is the size of the sales team? o Is it spread across geographies or some other meaningful distinction? o How is sales performance measured? o Do all people within the sales organization get to see all data (account, contacts, and opportunities) or are there divisions? o Are there any 3rd party companies involved in activities such as cold calling or lead qualification? If Service Cloud: o How the service organization structured? If both Sales and Service Cloud:
4

Copyright 2011 Clear Task, Inc.

o Can all team members see all data from each others groups? Is the Salesforce Customer or Partner Portal being implemented? What 3rd party integrations, if any, is part of the implementation? What Salesforce edition is being deployed?

Build The Right Foundation

As stated previously the primary focus and time expended on an implementation is the creation of user feature/ functions. Creating objects, fields, page layouts, reports, dashboards, and potentially migrating data from another system. It is time consuming work because of its nature. Creating a sound security foundation by contrast (at least for easy to moderate complexity environments) is relatively time efficient. There are a small number of key security settings needed to ensure secure insight for your users.

Organization Wide Defaults (OWD):

Explanation: OWD sets the default sharing model for each object. It is the baseline visibility model before any exceptions are added. Options range from: o Public Read/ Write o Public Read Only o Private o Controlled By Parent (for child objects in a master-detail relationship) where the child inherits the setting of its parent The Salesforce factory setting is Public Read/ Write, which is the most open model meaning all users potentially (assuming their profile allows it) have full access to all records Many companies incorrectly do not consider to change from the factory setting to a setting more appropriate for their implementation

Clear Task Recommendations & Best Practices: The OWD decision is largely driven by the intent of the implementation and the size of the company. For example:

Copyright 2011 Clear Task, Inc.

o A small company (<50 users), that has not deployed any Salesforce portals may be best served by a Public Read/ Write or Public Read Only model. They may not have a full time Salesforce administrator to create sharing rules, and their business environment, given their size, may be more open and collaborative in nature. o A medium to large company with larger sales organizations, that has perhaps deployed Salesforce portals, is best served with a Private model on most if not all objects. This affords the company the greatest level of baseline security, and subsequent exceptions can be created as needed. This is vitally important when the company has deployed the Customer or Partner Portal. Grant the permission to install applications from the AppExchange sparingly as: o These applications inherit the OWD from the applications publisher instance, and in many cases this is public. o Companies tend to click through the installation process without full regard or understanding of requested security settings. Under-utilized Features: The Grant Access Using Hierarchies option is an under-utilized OWD feature that can limit custom object data visibility. When this option is de-selected for a given custom object, (most) users that are higher in the role or territory hierarchy don't receive automatic access. This can be an effective way to limit upstream visibility.

Role Hierarchy:
Explanation: The role hierarchy is a (administrator) user defined arbitrary hierarchy, in many cases loosely mirroring the organizations management and/ or sales hierarchy. Roles can control the level of visibility that users have into a companys data. With some edge case exceptions, users at any given role level can view, edit, and report on all data owned by or shared with users below them in the hierarchy. Roles can be a very powerful way to easily secure data using the base construct that users at a given level cannot generally see each others data, but users above them in the hierarchy generally get to see all data below them Additionally since the role hierarchy, particularly in CRM use cases, generally resemble the sales organization structure, the role hierarchy provides a powerful reporting aggregation or group by

Copyright 2011 Clear Task, Inc.

Clear Task Recommendations & Best Practices: Clear Task has seen a trend where the role hierarchy is under-utilized by small and medium sized companies, either because the companies do not understand the full power of the hierarchy or these companies have a more open data model so the argument for using the role hierarchy to secure data is not as strong Larger companies tend to be more enlightened about how to structure the role hierarchy, but also many large companies struggle with the construct usually because of the size the hierarchy can grow to, which is only compounded by periodic territory realignment. Clear Task recommends: o Building out the role hierarchy from the start, regardless of organization size or prevailing OWD. Organizations changes, OWD evolve and generally become less open as more users are added to the system. And lastly there are reporting advantages to having users assigned to a role, namely being able to report by role, and have users select my teamss opportunities, o Balancing between granularity and system manageability. Do not create a role for each title or person. Do not blindly mimic the organization chart.

Under-utilized Features While the standard understanding of the role hierarchy is that users above me can see my records and users at my level cannot see my records, there is added granularity available to handle access/ view/ edit rights on opportunities and cases as the following screenshots demonstrate. Many companies forget this added granular access available from the edit link next to the given roles name.

Copyright 2011 Clear Task, Inc.

Sharing Rules: Explanation: Sharing rules provide a powerful way to create exceptions to OWD. These exceptions can be targeted at a single point in the role hierarchy or broadly to an entire branch of the hierarchy. Sharing rules also provide the flexibility to determine the nature of the sharing exception read only or read/ write. There are many examples of why sharing rules are used including: o The Lead OWD may be Private so partners cannot see all lead records, but a company may want to have an internal/ non-partner open/ public model. Create a simple sharing rule to open up all leads to the internal users only o A marketing group, represented by an identifiable node in the role hierarchy, will benefit from a single sharing rule to share all accounts and contacts with that role hierarchy node. o Similarly the service group may need to see all accounts in order to get details on what level of support companies are entitled, and to access contact details. Clear Task Recommendations & Best Practices: While sharing rules provide a tremendous amount of flexibility there is cause for concern when there is a large number of sharing rules in any given object. Large in this context varies based on the number of deployed users but Clear Task has been introduced to environments where there are 20 or more sharing rules per object. From an administration perspective a large number of sharing rules generally results in one or more of the following: o Un-intended sharing or records o Redundant rules, especially prevalent over time with multiple administrators o Misunderstanding of the impact of choosing Internal & Subordinates and Internal and Portal Subordinates o A poor role hierarchy design which the sharing rules are trying to counter balance

Copyright 2011 Clear Task, Inc.

 The example to the right demonstrates how to create effectively a public read write model (for accounts, opportunities and cases) for all internal users, by sharing all accounts owned by internal or portal users with all internal users Clear Task recommend that sharing rules be: o Used sparingly and only after the OWD decision and role hierarchy design is complete. No pun intended, but sharing rules should be the exception not the rule! o Reviewed periodically to ensure there is no redundant or un-intended sharing. A restructuring of the role hierarchy, or simply the passage of time (every 6 to 12 months) warrants a review of implemented sharing rules.

Under-utilized Features The Spring 11 release introduced the concept of criteria-based sharing rules for accounts, cases, contacts, opportunities, and custom objects. These rules determine whom to share records with based on field values in the records themselves. For example, create an account rule to share all accounts where Billing Country = Germany with the Role EMEA Marketing The feature is a compelling field value based approach to sharing records. Note, however, that normal role hierarchy rules apply in that users above the shared user in the hierarchy can still access the records.

Object Configuration: Explanation: This covers the process of creating new objects and of customizing both standard and custom objects by creating new fields. The focus for this document is on: o Page layouts
Copyright 2011 Clear Task, Inc. 9

o Field level security o Portal options Clear Task Recommendations & Best Practices: Clear Task has observed an over-reliance on the Page layout as the construct to hide fields from users. While conceptually excluding a field from a page layout removes the users ability to see the field when viewing a record, there are many other application areas where the field can surface, including: o Report creation user interface, or when viewing canned reports o List views o Search results page o Related list from a parent/ referenced record o Etc. Using field level security, while administratively more involved and time consuming is a more effective way to guarantee that a particular user profile does not have access to a specific field. Clear Task recommends weighing the risk of a given field being exposed somewhere other than a record page layout. It may be low for many fields but highly important for sensitive data like salary, date of birth, or social security numbers. Take a more conservative approach and use field level security when in doubt.

Copyright 2011 Clear Task, Inc.

10

The document to date has been focused on the primary ways to manage Salesforce data visibility. The focus now shifts to examining effective way to manage permissions both data access level permissions, and Salesforce feature level permissions. While OWD, sharing rules, profiles, and the role hierarchy are (correctly) thought of as the main influencers of system security, being too open in user profile definition can cause a lot of harm to data quality and integrity. This section reviews some of the top security related profile permission settings.

Standard & Custom Object Permissions: Explanation: While OWD, sharing rules, and the role hierarchy control what records users see if they are granted access to a given object, the Object Permissions settings control the access level (i.e., Read, Create, Edit, Delete) to these records. Object permissions are a very useful complement to the visibility settings since they are more granular in nature as they are administered at a profile level, and in theory there is no limit (other than a practical one) to the number of profiles. Salesforce provides two important overrides View All and Modify All that when checked allow users assigned to the given profile the ability to view and modify respectively all records of that objects type regardless of the sharing setting for that object. Clear Task Recommendations & Best Practices: Clear Task has experienced one of two extremes, either: o Companies are not as diligent as they should be with object permissions, and only change them when there is some unintended sharing or data update. Many companies simply Clone the Standard User profile, which has full access for practically all objects. o Companies go overboard and define too many profiles in order to have extreme granular control over object permissions. Other object permission bad practices include:

Copyright 2011 Clear Task, Inc.

11

o When dealing with portal user profiles, the profile (and portal definition) may not expose a tab for a given object but the object permission itself may grant the user access to the record. This brings the possibility that records will be visible to the portal user through the search function or through a report, and that the portal user may be able to change that data. o Excessive granting of the View All and Modify All permission to the point where the security model has become effectively internally open regardless of the OWD setting, since granting the permission opens up permission also to users above the assigned users through the role hierarchy definition. Clear Task recommends the following best practices: o Just as some upfront design consideration and thought is required for OWD and sharing rules, devise a profile design approach upfront that groups the major user groups into a manageable set of profiles. o Manageable will vary by the number of deployed Salesforce users and the range of deployed processes/ clouds, but suffice to say try to avoid derivations of the same profile with a small number of changes between them. Make some hard choices, weigh the benefit of added profile to cater to perceived exceptions. [There is an upcoming Salesforce feature called Permission Sets, which aims to help prevent an increasing number of profiles] o Grant the View All and Modify All permission sparingly. While there are legitimate instances for its use, it should be the exception rather than the rule. An over use likely indicates that its time to rethink the OWD/ sharing rules/ and role hierarchy. o Pay special attention to portal user profiles to ensure that they do not have unnecessary access to objects.

Administrative & General User Permissions Explanation: Administrative and general user permissions grant access to features as opposed to data. That said, the permissions granted can have a tremendous impact on the system data and usability. As such thought needs to be given to what permissions are granted. At a high level: o Administrative Permissions are very system feature centric and control what system features other users can manage, such as managing list view, content categories, public reports, users etc.
12

Copyright 2011 Clear Task, Inc.

o General User Permissions are most data centric in that they control what users can do with certain types of data. E.g., Convert leads, override forecasts, import leads, approve contracts, etc.

Clear Task Recommendations & Best Practices: Avoid System Administrator assignment creep! Many companies, especially smaller ones that may not have a full time Salesforce administrator, have the tendency to grant the System Administrator profile to too many people in order to empower the to make the changes they need. Bad idea! The result will be a system: o That does not have a consistent look and feel o Redundant and duplicate field definitions o Little to no customization of the user experience o Poor data quality Grant Administrative permissions sparingly. These are extremely powerful permissions that can impact how a Salesforce instance is configured and should be reserved for quasi administrators. Of note, any permission starting with the word Manage gives the user great control over what they can do in the system. Exercise care when granting Manage Public Documents/ List Views/ Reports as anything created by users with this permission becomes public unless the user remembers to lock security down using the objects security settings. Grant View All Data and Modify All Data permissions sparingly/ on an exception basis. From a security perspective the case and lead related general administration permissions (e.g., Convert Leads, Import Leads, Manage Leads, Manage Cases, etc.) have the most impact on data quality and should be looked at in the overall context of your organization/ team structure, business process definition, and data strategy. For example, should partners be allowed to convert leads? What impact does this have on data quality? Will there be duplicate accounts created as a result? Or should lead conversion be centralized in order to minimize duplicates? Consider creating a profile for employees that have given notice but have not left yet. In that profile lock down permission such as: o Export and Import permissions (e.g. Export Reports) o API Enabled (so they cannot use the Salesforce Data Loader) o Manage anything

Copyright 2011 Clear Task, Inc.

13

Additionally: Consider locking down the IP range (such as from corporate IP ranges) from which they can log in. Monitor the hours and IP ranges periodically before they leave the company Institute turning off Salesforce access as part of the employee exit process

Managing For Exceptions

There are times when on an individual record a user (typically the record owner) wants to make an exception to the previously discussed visibility and permission settings. For example: A sales executive that owns an opportunity may want to collaborate on the deal with a user from a different node in the role hierarchy An account executive may want to include a support user on an account A user may want to share a custom object that is set up as private with another user Salesforce provides the following constructs to open up sharing for individual records, where the aforementioned exceptions occur. Account Teams

Allow users to give other users access, or increased access from the prevailing security model, to an account and its related opportunities and cases. Sales Teams

The sales team allows users to give other users access, or increased access from the prevailing security model, to a
14

Copyright 2011 Clear Task, Inc.

specific opportunity Manual Sharing

When an object OWD is set as Private there is an optional Sharing button that when placed on the layout brings up an interface to include additional users/ public groups/ roles, etc. to access the record in a read only or read write mode.

Clear Task has also created a free application called Multi-Tier visibility which allows companies to automatically create manual sharing rules based on user entered data http://appexchange.salesforce.com/listingDetail?listingId=a0N30000001tN5WEAU Many companies use PRM have deployed this application as way to increase collaboration between partner accounts in a secure way.

Advanced Visibility Topics

Territory Management No discussion of data security would be completed without touching on territory management, a native and powerful alternative to the standard role hierarchy. Territory management uses a rules based approach to share access to accounts (and their associated contacts, opportunities, and cases) based on the characteristics of the accounts such as zip code, industry, revenue, or a custom field that is relevant to the customers business. There are pros and cons to using Territory Management, which is beyond the scope of this document, but for organizations that need a private sharing model and have a complex/
Copyright 2011 Clear Task, Inc. 15

matrixed sales model based on account attributes an investigation of territory management feature is warranted. There are several public resources available on this topic including: http://www.salesforce.com/customer-resources/learningcenter/details/best-practices/steps-to-deciding-if-territory-managementis-right-for-you.jsp http://www.google.com/search?q=salesforce+territory+management

Multiple Salesforce Instances There are rare cases where, unfortunately, the security model and related Salesforce features do not simultaneously meet the needs of all of the organization business constituents sales, HR, procurement, etc. meaning the model cannot be constructed in such a way to simultaneously provide the visibility, permissions, and reporting required by the different type of users and use cases. Clear Task has observed that in these cases companies may choose to have multiple instances of Salesforce, with each one optimized for their given business process. The down sides are: Multiple logins for users that need access to more than one system, although this can be mitigated with SSO Consolidated reporting across instances Syncing important data between instances, although this can be mitigated by using Salesforce to Salesforce or other 3rd party data integration solutions This scenario is best considered when the instances are relatively autonomous of each other and there is a compelling security reason to separate instances, such as for a HR system where the data is extremely sensitive.

Closing
Clear Task hopes that this document was helpful and highlighted best practices, common mistakes, and unknown product features that will help make your Salesforce instance more secure, user friendly, and helping achieve your business objectives.

Copyright 2011 Clear Task, Inc.

16