This is the final installment in a four-part series covering (almost) everything you need to know about salesforce.com security. In 101, we discussed all security components in Salesforce that govern data security, with definitions and common use cases. Followed by 102, which covered application security. In this installment, we'll take a deeper dive into application security, addressing advanced use cases of app security components, as well as examining some new components from the Spring '14 release, such as Salesforce Identity. There may be some repetition in definitions and such, but I want to make sure enough context is given when needed.
I’ve attempted to highlight the most common issues and pitfalls, however, there may be additional issues you face, and other considerations to keep in mind when designing your security model. Please use this set of blog posts as one of your many building blocks of Force.com knowledge and extertise. This series is not meant to be a sole replacement for salesforce.com’s documentation and advanced whitepapers, but rather an important supplement, touching on all aspects of the Force.com security model. Safe Harbor statements aside, let’s dig in!
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 data 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 ‘remodeling’ 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 (FLS), 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. 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 - Architectural Considerations
One point I’d like to reiterate from the use-cases in 102 is that it’s very important to limit the number of profiles in your org as much as possible. I’ve seen some pretty disorganized security models, with many redundant, unneeded profiles. It’s an arduous task to manage each profile since there are so many different points of configuration, so try to find the biggest groups of users possible for each profile.
You might even consider including a ‘shell’ profile, that grants minimal, or almost no access. Then, if you need to add one-off users that need very specific access—say, a Marketing partner that is sending new opportunities via API or ETL, such as (my favorite) Informatica Cloud—you may only need to ‘create’ Access to Opportunity, with no access to any other objects or tabs. This ensures the user account is only used for the purposes initially intended and is not exposing any data to outside parties. This opportunity permission can be granted by assigning the ‘shell’ profile with ZERO access to anything, and also adding a permission set that includes ‘Create’ on Opportunities only.
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 - Architectural Considerations
As mentioned in profile considerations, permission sets can be used to have tight granular control over which users can access what content. Depending on this size of your org, the way you use permission sets could simplify or complicate your life. If it starts looking like a mess, you’ll want to perform regular audits to avoid redundancies. It is possible that your permission sets are too granular if the same users have many different permission sets. On the other hand, it’s also possible that they are too broad if few permission sets each contain many permissions, opening up unneeded/unintended access to certain users. Of course, this all depends on what your business needs are. In any situation, routine ‘health checks’ and ‘sanity checks,’ can be extremely beneficial.
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 - Architectural Considerations
Custom settings can really make the difference between a scalable, easy to maintain deployment, and a very frustrating deployment. If the extra effort is put forth to organize custom code, allowing configuration in as many places as possible, your custom development can grow with your evolving business. Let’s say you have a custom search function that checks for duplicate accounts when logging new cases or leads. You may need it to behave differently depending on which user role is logging the case. You could have the code reference a custom setting table that ‘maps’ access levels/behavior to specific roles. Sure, you could hard-code the roles into the APEX class to suit today’s needs, but what happens 6-12 months down the road when you deploy a Community or implement new business processes for additional departments? You would have to track down the original developer and pay to have it changed to accommodate your new business needs, or hire a new developer and pay extra while they figure out “what the H” the original developer was thinking. Or, how about simply adding the new roles to the custom setting table, at the appropriate access level? This can go from a 5-10 minute task that your internal admin can handle, into a costly little development effort.
Account and Opportunity Teams - Definition
An account/opportunity team is a team of users that work together on an account/opportunity. For example, your account team may include an executive sponsor, dedicated support representative, and project manager.
You can build an account team on each account that you own. When selecting an account team member, choose a role to indicate the role the person plays on the account. Also, depending on your sharing model, you can specify the level of access each account team member will have to the account and any contacts, opportunities, or cases associated with that account. So, you can give some team members read-only access and others read/write access.
Account and Opportunity Teams - Architectural Considerations
I don’t have too much to add from the beginner’s version, but I wanted to share the ERD/Data Model so you can get a visual of all the objects/tables involved with sharing and Account/Opportunity Team Sharing.
Force.com Feature Licences - 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 (which we discussed in detail in 102).
Salesforce.com and Force.com also have several feature licenses, which entitle users to additional features such as Marketing or Call Center.
Force.com Feature Licenses - Architectural Considerations
As Feature licenses open up essential functionality, it is imperative you evaluate which functionality will be needed. I won’t go into cost, as this can vary greatly depending on your contract, but salesforce.com is typically pretty good about working with you to make sure you’ll have the functionality you need to be successful. Many desired features may already be included in your contract, but you can always try to negotiate any of these to help sweeten the pot for your CFO. Below is a breakdown of the feature licenses available, with additional commentary when necessary.
It’s also very important to understand the limits of the platform/license type. A full breakdown of Salesforce.com limits can be found here.
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 - 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.
Also, any API/ETL users will need access to the fields they are writing to, so ensure these users have profiles or permission sets that grant field level security to the appropriate fields.
Salesforce Identity - Definition
I’m not sure that I could top the definition straight from DeveloperForce: As the number of cloud-based providers and applications continue to grow, users are faced with an ever-growing array of login options and credentials. This trend poses a problem for not only users, but administrators and developers looking to leverage a full ecosystem of applications and features within the cloud.
Salesforce Identity provides Identity and Access Management (IAM) for Web and mobile applications through the simplicity, transparency, and trust of the Salesforce Platform. Salesforce Identity helps to improve the usability and adoption of applications through single sign-on for end users, simplify administration through centralization and automation of user identity and access rights, and provide peace of mind for the CIO through visibility and control over their cloud investments.
Salesforce Identity - Use
So what does this mean for current Salesforce users? Well, if you already have Enterprise or Unlimited/Performance Editions, it’s already included.
One of the main goals of Salesforce Identity was to make authentication, Single Sign-On (SSO) and directory services available to companies, whether or not they’re already using Salesforce. Since there’s so many different uses and considerations, certainly enough information to fill an article series of its own, I’ll just highlight some of the major features and point out what it means for companies using Salesforce vs companies not using Salesforce:
Salesforce.com Security Controls - Definition
I wanted to wrap up this series by touching on the Security Controls section, which is located in the setup menu:
It contains several different aspects of security, largely pertaining to global application settings, with the exception of Sharing Settings (OWD & Sharing Rules) and Field Accessibility (Field Level Security). Other settings include Network Access (allowed IP addresses), Session Settings and Authorization Partners. It also includes some admin tools relating to security such as the Setup Audit Trail (detailed log of all configuration done, by who with timestamp) and Portal Health Check.
While the default settings may be adequate for your organization, it should not be overlooked as there may be options that help your business, whether it’s providing additional layers of security, or enhancing user experience.
Salesforce.com Security Controls - Use
I’ll attempt to touch on each page within the Security Controls Section and highlight the most common aspects one might consider that have not yet been covered in this guide.
Speaking of ‘sanity checks,’ maybe I need one after completing this series. I tried to be as thorough as possible, however, I know there are so many more use cases, exceptions and scenarios that may come up. One of the recurring themes you may have noticed is that businesses scale and evolve—what might be right for you today doesn’t mean it will work for tomorrow. This is why with almost every component, you should be looking for ways to streamline the maintenance and modularize your environment as much as possible, so simple modifications don’t turn into major projects. If you can work some routine 'spring cleaning' I can almost guarantee it will save you time down the road, even if it does add to your task list now.
Think you’ve got some security chops now? Perhaps you should dig a little deeper into some of these advanced secuirty topics.
To stay secure you have to stay up to date. Download the latest report on how the best IT teams are using Salesforce here.
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.