The Definitive Guide to Salesforce Security: 102

This is the second installment in a four-part series covering everything you need to know about security. In my first post, we discussed all security components in Salesforce that govern data security, with definitions and common use cases. In this installment, we'll take a look at how these components fit into the big picture, by covering all security components that govern application security. I will also be releasing more advanced versions of both Data + Application Security early next year. Along with Definitions (some of which directly from Salesforce), you’ll find common use-cases, issues, and considerations. I’ve attempted to highlight the most common issues and pitfalls to avoid, but there may be additional issues you face and considerations to keep in mind when designing your security model.

The and security model is a combination two major components:

  • data security
    • Discussed in my last post, data security is comprised of components, rules, and objects that define and drive access or restrictions to data in Salesforce, e.g. who has access to certain accounts or contacts?
  • application security
    • What we’ll cover in this post—application security consists of the components, profiles, and permissions that govern which functionality and/or areas of the application users have access to, e.g. you may grant Marketing users the ability to export data and manage campaigns. Application Security Components

This section defines the components, profiles, and permissions that govern user access to various system components and application functionality, e.g. the ability to export data or manage campaigns.

In general, routine audits of all security components are recommended to ensure that your current security structure continues to satisfy your evolving business model and goals. This can require some arduous work unwinding years of band-aids and quick-fixes. Layering together numerous quick-fixes can result in an unorganized and unstable structure. At the time, one-off patches may seem appropriate, but enough of these exceptions will start to add up and you will have a haphazard conglomeration of code, patches and other settings. These can often be consolidated more efficiently if a little ‘re-modeling’ is conducted during spring-cleaning. Security Profiles security profiles - definition
As a major component of Salesforce’s security model, security profiles extend object permissions, tabs, field level security, APEX/Visualforce access, and app or system permissions to different users. Object permissions dictate which objects users have access to within a given profile, and the respective access within each object such as create, read, edit, delete (CRED), view all, and modify all. Salesforce comes with standard profiles as well as the ability to create custom profiles. Standard profiles cannot be customized, which is often why custom profiles are utilized, providing greater control over the various elements of the application users can access. The standard profiles are often used as a starting point, with many choosing to clone standard profiles into new custom profiles, which are further modified. Security Profiles - Use
Profiles are the main driver for who has access to what application functionality. So they are an absolutely essential cornerstone of any SFDC deployment. The only drawback to being able to control everything a user has access to from one place, is that profiles can become big & clunky; often multiplying into redundancies as an instance grows. So I often suggest taking steps to reduce the number of profiles as much as possible. I typically try and group major parts of the organization into as few profiles as possible, e.g. “Sales User,” “Marketing User,” “Manager,” etc. This allows you to still have control, without having to manage copious amounts of profiles. Then, to gain finer-grain control for certain elements, you can create permission sets to grant additional access to smaller groups of users. Read further for permission sets—profile permissions can trump OWD, e.g. “view all data.” Permission Set permission set - definition
Permission sets allow administrators to fine-tune user access to a collection of settings. Permission sets are designed to be used in conjunction with profiles. A user’s profile will establish the minimum amount of permissions they have within the system, while permission sets will open up additional functionality when combined with the profile. All access settings available in a permission set are also available in profiles. Permission sets can be assigned at the individual user level. Permission sets should be leveraged to avoid profiles getting out of hand. Permission Set - Use
Permission sets are really where the magic starts to happen when granting additional functionality to subsets of users. For example, you may only want to give a small group of users the ability to manage campaigns, or to bulk edit data. You may also have a VisualForce page that a small subset of users should have access to. I would remove these permissions from all profiles, and create one permission set for each one. This way, it’s very easy to add users to these permissions, making things much more clear as you know exactly who has access to certain functionality without having to click through several screens.

One quirk to permission sets is that users are added one-by one via the User record. this can be a painstaking process if several users need to be added. In this case, you might consider using a profile for the users, or managing the permission set assignments via an APEX Data Loader. Custom Settings custom settings - definition
Much like custom objects, custom settings allow administrators to create and associate custom sets of data for an organization, profile, or specific user. Custom setting data can be used in formula fields, validation rules, Apex, and the API without an additional cost of repeated queries to the database. Custom settings should be leveraged to eliminate the need to hardcode sets of data into custom code, establishing a very agile environment. custom settings - use
Custom Settings are what really sets the platform apart from other development, application and CRM platforms. You can basically create an application, trigger, or other component with custom code, and any possible variables, like field filters, and objects can be configured in custom settings. With this, any time a new custom field is created that needs to be included in an update action or filter within an APEX trigger (or other APEX code), the code would contain the API name of custom settings fields, which can then be configured through the GUI interface of custom settings via Salesforce setup. This way you don’t have to hire or contact a developer for minor changes.

So what does this have to do with security? Well, one type of custom settings is based on role hierarchy, so you can have different settings apply to each role. Thus, the app behaves differently depending on the running user. So cool! Reports and Dashboard Security report and dashboard security - definition
Folders dictate access to reports. Folders can be public, hidden, or shared and can be set to read-only or read/write. Access to a report folder and its contents can be controlled via roles, permissions, public groups, territories, and license types:

Administrators control access to dashboards by storing them in report folders. If you have access to a report folder, you can view its dashboards.

Folders control access to the reports and dashboards, but the running user determines access to dashboard data. The running user options for dashboards are:

  • Run as specified user
    • The dashboards run using the security settings of that single, specific user. All users with access to the dashboards see the same data, regardless of their own personal security settings. This approach is perfect for sharing the big picture across a hierarchy, or motivating team members by showing peer performance within a team. If you don’t have the “view all data” permission, you can only choose yourself. If you have the “view my team's dashboards” permission, you can choose any user below you in the role hierarchy.
  • Run as logged-in user
    • A dynamic dashboard runs using the security settings of the user viewing the dashboards. Each user sees the dashboards according to their own access level. This approach helps Administrators share one common set of dashboards components to users with different levels of access. reports and dashboards - use
We don’t really need to cover the obvious typical use of reports and dashboards, so instead we’ll focus on the security around reports and dashboards. As specified above, the security surrounding reports are comprised of two main aspects:

  • Report folder access
    • You are given a lot of flexibility here with who can view or edit reports. If you have a partner portal, you can also dictate which partner roles have access. This is helpful when you want to grant access to all internal users, but no portal users, or vice versa.
  • Data access
    • Even if users have access to reports via folder sharing, the data within the reports is still dictated by data security. Simply put—if you have do not have access to a record due to any data/application security settings, you will not have access via reports. So in effect, users may see different results by running the same report. This can be especially useful when leveraging reports to generate callings lists and such for Sales. Let’s imagine users need to see all open leads without open activities. Well, this cannot be achieved with list views, but you can do it (available with Enterprise Edition & Unlimited [Performance] Edition) with a cross-object report filter. More info on report filters here. In the past, I’ve taken this report and created a sidebar link or placed the link in a url tab so users have easy access. This type of report is dynamic, based on what data users have access to, and can dramatically increase efficiency. I go into more detail about dynamic reports from custom links and buttons in a related article about master data management tools for end-users. License Types license types - definition
There are many license types on the platform, used for different purposes. These include the standard Sales Cloud license, Service Cloud, Chatter Only, Chatter Plus, Community/Partner Portal, among others. All licenses are also driven by the edition of Salesforce you have:

  • Contact Manager
    • Basic contact management and activity management. Not very customizable, but Content, Chatter, and Salesforce for Outlook are included, so for $5/month it’s probably the best contact and activity manager (on steroids) you’ll find for the price.
  • Group
    • This includes basic CRM functionality. While still not customizable, it provides opportunity tracking, lead scoring/routing, and e-mail templates. Again, very high value for the price, but you must use the standard features. This license is up to 5 users.
  • Professional
    • Includes all of the CME and GE functionality plus mass email, campaigns, and customizable dashboards. It’s also more customizable, as you can create custom fields and page layouts, so it can be tailored to the way your Sales and Marketing operates. A lot of additional functionality can be achieved with AppExchange apps, but several apps are not available unless you have API enabled. Data management must use the Data Import Wizards (setup/admin UI) or
  • Enterprise
    • Enterprise is where you start getting the power of the platform. You now get workflow and approval processes in addition to APEX & VisualForce. This means you can completely customize the application to suit your business needs. This is also where custom security profiles come into play and role hierarchy has actual significance.
  • Unlimited (soon to be Performance Edition)
    • We’ll just refer to this in Winter ’14 terminology as Performance Edition. Most limits are increased over EE, and you receive an unlimited number of apps. You also get premier support and administrative services, which can be a great help to your internal admin.

A detailed comparison can be found here. *It’s also very important to understand the limits of the platform/license type. A full breakdown of limits can be found here. license types - use
Below are common license types, along with associated use-cases. The edition the org has (above) applies to all license types below.

  • Salesforce Sales Cloud
    • Designed for users who require full access to standard CRM and AppExchange apps. Users with this user license are entitled to access any standard or custom app. This is the primary license used for most users such as management, Sales users, Marketing, etc.
  • Salesforce Service Cloud
    • Designed for customer service/support personnel that require streamlined access to handle support issues via multiple channels. Service Cloud grants access to web-chat and the ability to create cases from Facebook and Twitter posts. You also get the Service Cloud console, which is a streamlined interface for accessing multiple related records on the same screen. With Winter ‘14, users are also able to edit up to 3 records at the same time, and includes a streamlined interface for logging interactions.
  • platform
    • Designed for users who need access to custom apps but not to standard CRM functionality. Users with this user license are entitled to use custom apps developed in your organization or installed from AppExchange. In addition, they are entitled to use core platform functionality such as accounts, contacts, reports, dashboards, documents, and custom tabs. These users are not entitled to some user permissions and standard apps, including standard tabs and objects such as forecasts and opportunities. Users with this license can also use connect offline. You can find more info on platform licenses here.
  • Chatter Only
    This is also known as Chatter Plus. Chatter Only is designed for Unlimited, Enterprise, and Professional edition users that don’t have Salesforce licenses but need access to some Salesforce objects in addition to Chatter. These users can access standard Chatter people, profiles, groups, and files, plus they can: Field Level Security field level security - definition
Field-level security (FLS) settings let administrators restrict users’ access to view and edit specific fields in:

  • Detail and edit pages
  • Related lists
  • List views
  • Reports
  • Connect Offline
  • Email and mail merge templates
  • Custom links
  • Synchronized data
  • Imported data

The fields that users see on detail and edit pages are a combination of page layouts and FLS settings. The most restrictive field access settings of the two always apply. For example, if a field is required in the page layout and read-only in the FLS settings, the field-level security overrides the page layout and the field will be read-only for the user. field level security - use
The most common use of FLS is to restrict access to certain fields for certain profiles. This prevents the fields from being visible or editable on page layouts and reports. The main advantage here is that you can use the same page layout for two profiles, while having different end-user experience based on the profile. For example, let’s say an account layout has standard sections, and there’s also fields for financial/billing data. Sales should not see this financial data, but an Accounting profile does. Assuming the layout is the same otherwise, you could just place these financial fields in a separate section, and the FLS would prevent the sensitive fields from displaying for sales, whereas the Sales rep might only see an overall status field in this section, e.g. “Billing Status = Active.” field level security - architect considerations
Even though users may not need access to certain fields on page layouts or list views, there may be times when they need to merge these fields into email templates or pdf templates. For example, when using a powerful mail merge application such as Conga Composer, users will need Read-access to any and all fields in the merge template, such as proposals, invoices, etc. In this case, you can still grant read only access to the fields included in a merge document, without adding them to any page layouts, lists or reports.

In our next installment, we graduate to The Definitive Guide to Salesforce Security: 103; taking a more advanced dive into data security. We’ll take a look at some of the primary architectural considerations that should be taken into account while designing a security model that can scale with your growth. Even though it will be focusing on advanced topics, any skill-set will benefit from reading, equipping you with additional tools you can use to design more sophisticated and scalable security models.

We surveyed over 1,500 companies to learn how the best IT teams are using Salesforce. Download the free report

Connect with an expert to learn more.



Bluewolf, an IBM Company, is a global consulting agency and proven Salesforce strategic partner that builds digital solutions designed to create results. Now.