Using data access design patterns

Data access, or record sharing, is the process by which users can see records within a single object, such as
the account object, or within child objects, such as the opportunity object. Data access also determines
which records are returned in searches, displayed in views, and shown in reports.
The design process for all implementations, regardless of size or scope,
starts with defining which records users are permitted to see. It’s a crucial
Abstract
step because a CRM system is a tool for making operational the data you Properly controlling access to sensitive
store about your business relationships. When users have access to the information in your system is vital to CRM
right data, they can work faster and more accurately. When they don’t, success. Start with this document to
understand all your options for sharing settings,
they waste time trying to find important information—even worse, they
role hierarchy, sharing rules, and territory
see sensitive data not appropriate to their job function. management.

This document is an ideal starting point if you’re implementing a large, By Tad Travis
enterprise-level system. Before you design, re-design, or implement
Salesforce CRM, be sure you understand all your data access options.

Design data access with clicks, not code

Salesforce CRM includes powerful, configurable functions for controlling access to records. Below are the
9 most important functions, listed in the order you should consider them during your design process. Please
note: Your data management options depend on your edition of Salesforce CRM.
1. Profile – For each object, set users’ read, create, edit, and delete permissions by controlling their
profile assignment. To see records in an object, a user’s profile must have at least read access.
2. Record ownership – Every record must be owned by a licensed salesforce.com user or by a queue
(for cases).
3. Sharing settings / organization-wide defaults – Use these settings to define the data access
model, which defaults to “always-on” rules for seeing records for each object.
4. Role hierarchy – Use the hierarchy to define your organization in a tree-like structure; it’s
essential to data access because it defines who can see data owned by other users.
5. Grant access via hierarchies – Enable default “always-on” rules for manager-level access to
specific objects.
6. Sharing rules – In restricted access models, use to enable “always-on” exception rules for wider
access by classes of users, for a specific object.
7. Manual sharing – Record owners can use manual sharing to give read and edit permissions to
users who would not have access to the record otherwise.
8. Account and sales teams – An account team is a team of users that work together on a single
account; a sales team is a group of users that work on a single opportunity.
9. Territory management – Use to provide access to account records depending on a user’s
assignment to one or more territories. This option is relevant to companies that maintain large,
geographically dispersed sales teams and manage large account record volumes/
Using data access design patterns

Together, these functions define your data access model, described on the next page.
The functions are interdependent, meaning that when users retrieve records, each component is evaluated
progressively, in real time. Each time a user queries the system, Salesforce CRM evaluates the meta-data
rules underlying each component, returning only those records that meet the filtering criteria. For an
excellent example of the how these rules are sequenced and evaluated, see the model in Help and Training.
For detailed information on configurable profiles, org-wide defaults, the role hierarchy, and sharing rules
settings, please see the Tips and Hints document in Help and Training. This document will also help you
understand the sequence of actions the system takes to determine real-time access to records.
You’ll notice that reporting is not included in this list. Data access and reporting are two different things.
You need to account for all record access components before you can build reports, otherwise users won’t
be able to see the appropriate records in their reports or views. Field-level settings are also not included in
this list; however, more information on field-level security is available in Help and Training.
The remainder of this document explores the most important design considerations for enterprise
implementations: your data access model, sharing settings (default org-wide object defaults), the role
hierarchy, sharing rules, and territory management.

About data access models

Before configuring your system, it’s a best practice describe your high-level data access requirements in the
form of a data access model. The model is an abstraction, but it’s a useful tool for describing what kinds of
records certain classes of users can access. There are 3 types of data access models. Each model is defined
by the default sharing model, which you configure with the organization-wide defaults and record
ownership rules. Review these options to determine the best fit for your company.
Many other apps can also make your marketing campaigns sing!
1. Private access model – Users are prohibited from accessing most account, contact, opportunity,
activity, and custom object records of other users, even in their departments. If you want these
restrictions, a private model is best.

Requirements
You want to restrict access to accounts, contacts, opportunities, and
cases among users who perform similar job functions. For example,
reps in two different districts can’t view each other’s opportunities.

You plan to use the partner portal. A private model will prevent
inadvertently exposing sensitive records to partner users.

You have large data volumes. A private model will help restrict the
number of records returned in searches, views, and reports.

You plan to use territory management.

Not many large companies—except possibly financial services firms—use a fully private sharing model
because it has a significant impact on the data returned in reports and searches. So consider all your
business requirements before proceeding with this model.
2. Public access model – If you have no restrictions on accounts, contacts, opportunities, activities,
cases, or custom object access, then a public model is best. This model results in immediate
productivity improvements because it saves data retrieval time and makes it easier for colleagues
to collaborate.
3. Hybrid access model – In this model, users have unlimited access to most standard objects, but
are restricted from accessing records not directly related to their job functions. Most enterprise-
level companies use a hybrid model.

BEST PRACTICE 2
Using data access design patterns

If it’s obvious that a public model meets your needs, then configure your per-object organization-wide
defaults with either Public Read/Write or Public Read Only settings (see the next section for an
explanation). But if you decide a private or hybrid model is appropriate for your organization, review all
the configuration considerations below.
Defining organization-wide defaults and record ownership
Your first step in setting a private or hybrid model is to configure your organization-wide defaults and
record ownership rules. The organization-wide defaults specify the default, always-on level of access to a
record. These defaults can be set separately for accounts (including assets and contracts), activities,
contacts, campaigns, cases, leads, opportunities, calendars, price books, and custom objects. For most
objects, organization-wide defaults can be set to Private, Public Read Only, or Public Read/Write. See
Sharing Model Fields for your options.
Every record must by “owned” by a licensed salesforce.com user or a queue (for cases), as shown in these
examples:
Account record

Opportunity record

Case record

Record ownership has two important implications on the data access model. First, it determines default
read/write access, meaning that record owners can always read and edit records they own. Second,
ownership also drives the default reporting functions on the account and opportunity reports.
How do these functions work together? Below is an example of a typical hybrid model.

Object Sharing setting Record owner Explanation

Accounts Public Read Only Jessica Cho (CEO) No record viewing restrictions

Contacts Controlled by Parent Wendy West (AE)

Activities Controlled by Parent Wendy West (AE) Activities public if associated

with public object; otherwise,
they’re private

Opportunities Private Cindy Central (AE) Accessible only to record owners

and users above them in the role
hierarchy

Cases Public Tier 2 Escalation Queue Any user can view and edit cases
Read/Write/Transfer

Business plan Private Cindy Central (AE) Accessible only to record owners
(child to account) and users above them in the role
hierarchy

For a detailed definition of the sharing setting values, please see Help and Training.

BEST PRACTICE 3
Using data access design patterns

Defining the role hierarchy

The role hierarchy is the third component of the data access model. It’s as important as sharing rules for
determining record access in private or hybrid models. Users are assigned to a branch in the role hierarchy
to give them the proper default access to records owned by other users.
Users at any given level in the hierarchy can view, edit, and report on all data owned by or shared with
users below them in the hierarchy, regardless of the organization’s sharing model. This approach ensures
that managers can always access the same data as their employees, regardless of the organization-wide
default settings.
Your role hierarchy usually mirrors your sales organization structure or your support center structure, but it
need not match your organization chart exactly. For examples of common role hierarchy design patterns,
see the table below.

Example Description

Operations users need access to all records, so they

are assigned to the same node as the CEO. Users who
need access to the greatest number of records,
regardless of object, should be assigned to a role near
the top of the hierarchy. This requirement often
results in a role hierarchy that puts analysts above
SVPs, but that’s a perfectly acceptable design.
Users in the CFO node own confidential records such
as contracts and business development plans, so they
have their own role node. These users can access
private records owned by sales users via sharing rules.
To grant the SVP Customer Service and Support
access to all sales-related records, sales & marketing
roll up to customer service and support.

Every user must be assigned to a role or his/her data

will not display in opportunity reports, forecast roll-
ups, and other displays based on roles.
The sales organization uses both direct and indirect
(channel) sales roles because each group submits
independent sales forecasts.
Representatives can only be assigned to a single
regional sales team.
Members of the East Team can view all the
opportunities owned by users with the East role, but
West Team users cannot view those roles, thanks to
the role hierarchy.
It’s also common to create a separate role for each
unique sales territory within each sales region.

For additional configuration information about role hierarchy functions, see Help and Training.
Role hierarchy design considerations
Because the role hierarchy is so critical to your data access design, be sure to address the considerations in
the following table before moving forward.
Research shows that customers who are trained by salesforce.com achieve a 52 percent higher adoption
rate. Be sure to take advantage of the free training available from the Help & Training links in your
application and on the Salesforce.com Community Web site.

BEST PRACTICE 4
Using data access design patterns

Consideration This means that….

Design trade-off: too much vs. too little abstraction The greater the number of roles, the greater the change management
burden. Too few roles and your reports don’t have the right
granularity or it will be more difficult to implement content
workgroups. There is no mathematical function that calculates the
right number of roles for your organization, so be prepared to
develop your roles iteratively.

Customized forecasting hierarchy is cloned from the If you plan to use customized forecasting, your role hierarchy
role hierarchy should mirror your sales or support organization. Updates to your
role hierarchy do not update your customized forecasting hierarchy.

When territory management (TM) is deployed, the Users at the top of the role hierarchy will have access to accounts
role hierarchy and TM both govern record access and opportunities, even if opportunities are private and access is
proscribed by TM. In the case of overlapping rules, the most
permissive setting wins.

Grant access using hierarchies is always enabled on In a private data access model, users at the top of the role hierarchy
all standard objects will have access to accounts and opportunities. By default, users
in different branches of the hierarchy cannot see one another’s
opportunities.

Grant access using hierarchies must be enabled on all This setting is necessary to prevent exposing sensitive records to
custom objects displayed in the customer or partner portal users. Additionally, restrict access by portal users using new
portals sharing rules that include the setting “roles and internal
subordinates.”

Exceptions to role hierarchy access Use sharing

Sharing: managing exceptions to the rules

If you set the organization-wide sharing defaults to Public Read Only or Private on some objects, you can
define rules that give additional users access to records they do not own.
Sharing rules can only be used to grant additional access, not to restrict access to records beyond
restrictions originally specified with the sharing model through organization-wide defaults. You can create
sharing rules that are based on the record owner or on the record’s field values.
To provide additional access, salesforce.com provides 4 classes of sharing functions to manage always-on
and one-off exceptions to your private sharing model.
1. Sharing rules – You can use sharing rules to automatically grant selective record access to
defined sets of users, based on record ownership or on the record’s field values. You can define up
to 100 owner-based sharing rules for each object. Sharing rules are ideal for granting broad types
of access. Records owned by internal roles, territories, public groups, queues, and portal roles can
be shared with internal roles, customers, or portal users. Sharing rules are also important for
granting granular record access, where records owned by a specific role can be shared more
broadly with internal roles.
Note: Sharing rule permissions depend on your edition. See Help and Training for additional
information.
2. Manual sharing – Because it’s often difficult to define every sharing rule users need, manual
sharing is ideal for allowing one-off record access to classes of users who would not have access
in any other way. Manual sharing isn’t automated; record owners must manually share each record
that requires wider access.
Sharing rules address the following typical scenario: An APAC sales representative owns the
business relationship with an international manufacturer, which has subsidiary companies in the
U.S. and Germany. A local U.S. representative finds a new opportunity with the U.S. subsidiary,
which is required to get funding approval from the parent company. To drive the deal, the U.S.

BEST PRACTICE 5
Using data access design patterns

representative grants read-write access on her opportunity to her APAC counterpart. For more
information on configuring manual sharing, see Help and Training.
3. Account teams and sales Teams – Account teams give users the freedom to set default account
teams that include those employees who normally work together on an account. Users can
automatically add default account teams to all accounts. Sales teams can do the same while
working on opportunities.
4. Apex managed sharing – Apex managed sharing lets developers use Force.com code (Apex) to
programmatically share custom objects. When you use Apex managed sharing to share a custom
object, only users with the Modify All Data permission can add or change the sharing on the
custom object’s record. Also, the sharing access is maintained across record owner changes. For
more information on Apex managed sharing, see the Force.com Apex Code Developer’s Guide.
You can use all these methods for the following sharing options: public groups, personal groups, users,
roles, roles and subordinates, roles and internal subordinates, internal and portal subordinates, territories,
and territories and subordinates. See Help and Training for definitions and usage recommendations.
Sharing design considerations
Sharing rules makes it possible to be flexible when assigning record access; be sure to review the following
considerations before adding sharing rules to your system.

Consideration This means that….

Opportunity and case access when accounts are When sharing an opportunity or case, users must have at least read
private access to the associated account (unless you’re sharing a case via a
case team). If you also have privileges to share the account, users
are automatically given read access to the account. If you don’t
have privileges to share the account, you must ask the account
owner to give the users read access.

Contact access Contact access is not available when the organization-wide default
for contacts is set to Controlled by Parent.

Controlling access to associated child records For sharing rules that specify access for associated object records,
the given access level applies only to that sharing rule. For
example, if an account sharing rule specifies Private as the access
level for associated contacts, a user may still have access to
associated contacts via other means, such as the organization-wide
defaults, the “Modify All Data” or “View All Data” administrative
permission, or the “Modify All” or “View All” object permission.

Apex sharing reasons If using Apex sharing reasons, select a reason for the share so users
and administrators understand the source of the sharing. For more
information about sharing reasons, see Creating Apex Sharing
Reasons.

Territory Management: automate account access

Territory Management (TM) is the final component of the data access model. TM is designed to automate
how large volumes of account records are assigned to users, thanks to declarative business rules triggered
by account record attributes such as zip code, industry, revenue, or another custom field relevant to your
business.
Why use TM?
With TM, you immediately gain these benefits:

 Assign account records to territories with declarative business rules and explicit assignments –
Automate account record access to expand a private access model

 Organization management – Manage complex and frequently changing sales organization structures

BEST PRACTICE 6
Using data access design patterns

 Alignment and re-alignment – Get support for transferring users between territories, with the option to
retain opportunities

 Forecasting – Get multiple forecasts per user, based on territory membership

 Reporting – Gain the option to create territory-based sales reports
In addition to controlling access to accounts for users in each territory, you can control users’ access to the
opportunities and cases associated with those accounts, regardless of who owns the records. For more
information, see Territory Fields.
Is TM right for you?
TM is not appropriate for everyone. Don’t deploy TM unless your organization meets most of these
requirements:

 Automated assignment – You need to mass-assign or automatically assign account records using only
account criteria to expand a private sharing model

 Re-organization – Your organizational structure is complex or changes frequently

 Alignment and re-alignment – You need to automate the territory re-alignment (user-to-territory and
territory-to-account) process and also maintain explicit territory-to-account alignment conditions

 Forecasting – You need to submit forecasts at the territory level, not at the user level
 Reporting – You need territory-specific reports, not user- or role-specific reports
Typical companies that implement TM already have a mature territory management process, as is often the
case in the pharmaceutical, technology, and media industries. If your company doesn’t have such a process,
we recommend that you deploy TM only after you considered all its functions and are sure it meets your
needs. For more help deciding whether TM is right for you, see this Best Practice: “4 steps to deciding if
Territory Management is right for you.”
In addition, TM only governs the assignment of accounts and the standard objects that have a master-detail
relationship to accounts, opportunities, and contacts. For example, opportunities are included in TM, but
leads and activities are not. That means that, if you have private records such as “Business Plan” that are
children to accounts, access to those records is not automatically granted via territory associations.
Finally, TM can only be enabled in your instance if you have a full-copy sandbox. Contact Support if
you’re not certain whether you purchased or activated a sandbox.
Additional information is available in these resources:

 Territory Management FAQ

 Tips & Hints for Working with Territories
 Deploying Territory Management

BEST PRACTICE 7
Using data access design patterns

TM functional considerations
Once you enable TM it can’t be disabled, so evaluate the following features before proceeding:

Feature This means that….

Dynamic account-to-territory assignments Drive re-alignments and new record assignments using declarative
business rules, not code.

Explicit account-to-territory assignment If you use “named accounts” ownership or have ownership rule
exceptions, you can use TM to directly assign accounts to users via
each user’s association with a territory.

User-to-territory assignments Assignments are explicitly declared in the TM system.

A user can be assigned to >1 territory You can implement pods, overlays, and temporary territory
coverage functions.

A territory can have >1 user You can implement pods and shared territories.

Territory hierarchy granularity The hierarchy is an exact re-creation of your sales organization.

Role hierarchy vs. territory hierarchy If you implement TM, your territory hierarchy governs your default
record access in a private sharing model, which means you can
simplify your role hierarchy with fewer roles.
But territory management doesn’t supersede the role hierarchy. The
most permissive setting wins.

Account ownership Account ownership doesn’t have the same significance because TM
determines default record access in a private sharing model. Most
customers revert ownership to a single default record owner in this
case.

Inheritance of opportunities In some cases, opportunities automatically inherit the territory value
assigned to the account.

Re-alignment modeling and “what-if” analysis You cannot define more than one territory alignment, but
assignments can be tested using the “Preview Account Assignment”
function in sandbox.

API access Territories are exposed to the API, so you can load territories from
a .csv file. Additional API functions are included in Help &
Training.

Lastly, because of the scope of this functionality and its impact on record access, we highly recommend
that you consult with a TM expert from an implementation partner before proceeding.

Summary: Best practices for designing your data access model

Because the record access model is so important, plan to spend sufficient time on analysis and design.
Below are several recommendations and best practices, gleaned from the most complex implementations.

 Define your business requirements – Every complex implementation has complex requirements.
Create a list of the most important business needs, written as business requirements, as shown in the
examples below.

BEST PRACTICE 8
Using data access design patterns

Requirements
Accounts owned by Americas Inside Sales Representatives must be
accessible by all other Americas Direct Sales Representatives;
otherwise the accounts are private to all other users.

Opportunities owned by Global Account Managers must be

accessible to all Direct Sales Users.

Business Plan records are only editable by the owner of the record
and managers above the owner in the role hierarchy.

Customer Service Representatives must be able to access all

account and contact records, even if the account is owned by a user
who is not in the CSR’s region.

 Define use cases – Although use cases can be challenging to write, they are absolutely necessary to
explain your conceptual data access model to others. Use cases are also important for getting user
acceptance and for creating system testing scripts

 Analyze your requirements and use cases – After analyzing both, you can determine your data access
model (private, public model) and whether you should deploy TM

 Design your default object sharing settings for each object in your system
 Design sharing rules – Determine which exception requirements can be satisfied with sharing rules
versus one-off methods such as account teams or sharing

 Design your territory hierarchy – Include your sales organization structure and user-to-territory
assignments

 Design your territory assignment rules for automated account-to-territory assignments

Use an iterative design and build process. Complex businesses typically have complex requirements and
rules, so it’s common to not get everything right the first time. Design iteratively, test as you go, and be
prepared to make adjustments.
If you’re already running your business in Salesforce CRM, you may need to make immediate changes to
your access model. Despite the urgency, never test these changes in production to avoid inadvertently
exposing private records to users.
If you have questions about other implementation best practices, please go to the Salesforce.com Answers
Community, where you can get input from other salesforce.com users

For More Information

Contact your account executive to learn

how we can help you accelerate your
CRM success.

BP_DataAccessModel _2010-03-18