
As users are exploring the ways to leverage Force.com, confidential information related to company compliance, privacy, and financial statements are all on one platform. Obviously, security comes to the top of the agenda when building an app on Force.com.
Therefore, the key for data access control in Salesforce is:
To make sure the designated users can access the data they want to reach.
This means it is critical to control who sees what and to create the Force.com org such that it provides the appropriate range of data to appropriate users, to internal or sometimes external users.
Features Used for Data Access Control
Data access control is basically determined by the following elements:
– Profile – Field-Level Security – Organization-Wide Defaults – Sharing Rules
Basic Data Access Functions
The basic data access settings are configured in profiles. The CRUD functions (Create, Retrieve, Update, and Delete) determine the base of data access. Salesforce provides special user permissions such as “View All Data” and “Change All Data”, but when you apply these settings, thorough consideration may be required.
The trap of Data Access Control
There are certain user licenses that limit data access by default. Thus if you are the system administrator, it is important to consider which license type you assign to users.
※Note that the above evaluation should be completed prior to launching your Salesforce implementation.
[Differences of Data Access Range in Licenses]
– Force.com platform: Accounts / Contacts (view only), Custom Objects – Customer Portal: Opportunities are not available – Chatter Free: All objects are not available
Common Mistakes of Data Access Control
[Hiding Tabs]
Many people believe that by simply hiding tabs they can limit user access to certain data. However, it is not true! In Force.com, every single record is managed by a unique ID. So theoretically, once you get that unique ID, the record can be accessible anytime (only when access permission is applied to the record).
Also, it is possible to create a view if you know the prefix of objects. For example, the prefix of contacts is “003”. You can create a list view by typing as below:
https:// instance of SFDC(ap0.salesforce.com etc.)/003
Let’s look at an example to learn further. Suppose the below are the requirements for your organization:
– You have order transactions and product masters in your Salesforce org. – Order transactions have reference fields that identify product masters. – A Sales user selects a product master by using the lookup function when entering an order transaction. – Maintenance of Product Masters is only allowed to the system administrator, not sales users.
The system administrator is to manage the maintenance of product masters. Therefore displaying the product master tab only for the system administrator and hiding it to sales users is not enough to secure records to a full extent. This is because sales users perhaps could reach the detail page or the edit page if they find out the product ID. Thus, in this case, you need to configure “Retrieve” to the sales profile.
We often receive a request to hide certain fields to certain users from the security point of view. For this request, you might come up with the idea to create several page layouts and hide the fields on a particular layout to limit data exposure. However, still, this cannot completely assure data security.
With the page layout, it is possible to hide fields from the reference page or the edit page. However, a person can also access the data from the report or the view function, or even by using API. Therefore we recommend you to use “Field-Level Security” to meet the requirement.
The “Field-Level Security” feature guarantees data security as it is applied to the below as well:
[Field-Level Security can be Applied to:]
– Relative List – Report – View – API Access
Let’s look at an example. Suppose the below are the requirements for your organization.
– You have order transactions and product masters in your Salesforce org. – Order transactions have reference fields that identify product masters. – Internal sales users as well as external re-seller users input order transactions. – Product masters contain the cost information which cannot be seen by re-seller users.
In this case, let’s set Field-Level Security to the cost information. In many cases, external users have limited access to data compared to internal users. The system administrator needs to be careful when determining access control.
Useful Features for Examining Data Access
[Permission Sets]
Permission sets expand possibilities on what you can do for the system defined in the profiles.
Permission sets allow a user to expand CRUD operations for an object and Field-Level Security, just like a profile.
If you build an application on Force.com and then add a new application, it may be a huge hassle to reconfigure profiles for each combination of usage. Permission sets are useful for this occasion.

Important Points for Examining Profiles
A common mistake around profiles is to associate a company’s organization chart with profiles in Salesforce and simply create a mapping. However, if the company is a decent size, you may have complex division structures so changing the org structure would happen quite often. Below are some important points you need to consider when setting up profiles.
[Points to Note]
– Type of user – What do users expect to do on Force.com? – Do users only need to view the object? Or do they have to update? – What kind of license is applied to users?
Conclusion
In this post, we have covered the profile function from the data security aspect. I assume some of you may pursue becoming a salesforce.com Certified Technical Architect. I hope this will help your understanding!
The topic, data access control, will be surely included in the exam. However, it is said that almost 70 – 80 % of people have missed this security section on the review board. For that reason we can see how important it is to understand fully the topic and designing the best security control option is crucial.
Comments