Many years ago, I was negotiating a contract with a lawyer who said to me, “Good Fences Make Good Neighbors.” From his perspective, the lawyer wanted to protect his client by defining good customer service in as much detail as possible. Since this contract was our standard boiler plate agreement, used hundreds of times for several years, I was not really interested in spending more time and money making changes. While I can appreciate that the lawyer wanted to protect “his” client (I don’t think he understood that they were our client as well), I told him that what was written on the paper would not affect our behavior and if “his” client was dissatisfied for any reason that we would be happy to refund their money.
In preparation for this blog, I decided to lookup the origin of this saying and found that it comes from Robert Frost’s "Mending Wall," a poem published in 1914. In his poem, Frost and a neighbor were working to repair a wall that divided their property. During the repair, he tells his neighbor that he doesn't see the need for the wall, but his neighbor replies, “Good Fences Make Good Neighbors.” What, you ask, does this have to do with data visibility in Salesforce? It captures perfectly the opposing points of view that people have with respect to the issue of security or boundaries.
The basic goal of any CRM system is to provide information about customers for better sales performance and service quality. Typically, the more open a system (sharing more data), the more potential value it creates for the organization. Openness tends to drive user adoption up, while systems that are locked down tend to motivate users to find other means of tracking valuable customer information. In other words, instead of inputting the data into Salesforce, the employee will create some sort of personal silo that only they can access.
The issue is much more complex than the question, should you have any security or not? Instead, it is all about maintaining a balance between staying open enough for sales and service personnel to access information to do their jobs effectively and still protecting the companies’ information.
The good news is that Salesforce provides robust, granular control over security and data visibility through the use of Organization Wide Sharing Settings, Profiles, Roles, Permission Sets, Field Visibility and Sharing Rules. While some of the Salesforce implementations I have worked with over the years have been challenging from a security and data visibility perspective, I have not run into any companies whose requirements could not be met. It’s also possible to start out at one end of the spectrum and adopt a completely different approach over time without losing any data.
First let’s cover some of the basics. Salesforce provides the ability for most objects to be Private, Public Read Only or Public Read Write. In cases where objects are related to other objects, Contacts being related to Accounts for example, the visibility of the Contact or child object can be set to Controlled by the Parent (Account). While each company’s needs are unique, I am usually in favor of an open sharing model of Accounts and Contacts, ‘open’ being either Public Read Only or Public Read Write. This is especially recommended where different salespeople will sell and collaborate with other salespeople on the same Account and maybe even the same Contacts. However, if you are concerned with a disgruntled former salesperson bringing a list of Accounts and/or Contacts to their next job, you might consider not allowing them to print or export all Accounts and Contacts. If you are particularly concerned about data vulnerabilities it is also worth noting that Salesforce has a service where you can gather data on any user's actions and whether they have run and exported data. The service is called log analysis and you can learn more here.
With respect to the visibility of Opportunities, I have seen anything from Private to Public Read Write. Here is where the data visibility really depends on the specific business needs, such as a need for cross-selling. Salespeople need to be informed of which products and/or services have already been proposed or sold to existing customers. Additionally, salespeople benefit from knowing current customer sentiments as they attempt to convince them to expand the business relationship. Even if the salespeople sell unrelated products and services, it would be a mistake, in my opinion, for them not to have some visibility in to the state of the existing relationship. Here is a table pointing out the pros and cons of each of the data visibility settings:
| Description | Pros | Cons |
| Private |
|
|
| Public Read Only |
|
|
| Public Read/Write |
|
|
Earlier I pointed out that the further you move towards an open sharing model, the more users will be inclined to adopt the system. In my experience, companies usually face more challenges with user adoption than with people leaving the company with customer lists. If some disgruntled employee really wanted to get a customer list, no matter how secure it was, they would get it.
Data visibility/security can be a complex topic. Before you walk down the path of setting up your system, thoughtfully discuss visibility/security with the stakeholders and your Salesforce implementation consultants to find out how strongly they feel about the idea that “Good Fences Make Good Neighbors.”