This is the second installment in a four-part series covering everything you need to know about salesforce.com 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 Force.com and salesforce.com security model is a combination two major 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.
Force.com security profiles - definition
As a major component of Salesforce’s security model, Force.com 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.
Force.com 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.”
Force.com 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.
Force.com 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.
Force.com 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.
Force.com custom settings - use
Custom Settings are what really sets the Force.com 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!
Salesforce.com 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:
Salesforce.com 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:
Force.com license types - definition
There are many license types on the Force.com platform, used for different purposes. These include the standard salesforce.com 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:
Force.com license types - use
Below are common Force.com license types, along with associated use-cases. The edition the org has (above) applies to all license types below.
Salesforce.com field level security - definition
Field-level security (FLS) settings let administrators restrict users’ access to view and edit specific fields in:
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.
Salesforce.com 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.”
Salesforce.com 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 salesforce.com 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.
Highlights delivered to your inbox:
Bluewolf, an IBM Company, is a global consulting agency and proven Salesforce strategic partner that builds digital solutions designed to create results. Now.