By Kaitlyn Burns
The term “data security” can be frightening for many people, especially solo admins! However, never fear, by double-checking and enabling a few features, the worry over data security will be a thing of the past. Here are five tips to keep your data safe and secure.
Tip 1: Field Tracking is Your Friend
In Managed Services, one of the first things we check for is whether or not field history tracking has been turned on for heavily used Salesforce objects and fields. If it hasn’t yet been enabled, it’s one of the first changes we recommend to clients. Up to 20 fields on each object are allowed to have field history tracking enabled, so it’s important to identify which fields are a priority to track, such as an Opportunity Amount or a Contact’s First Name.
Once field history is enabled for an object, a new related list and report type is created. For example, when tracking is enabled for Contacts, add the “Contact History” to see the changes to the Contact record and a report “Contact History” is created. The field history data is available for 18 months via standard reporting and can be accessed for up to 24 months through the API using SOQL queries. The following pieces of data are created for each update to the field with field tracking enabled:
- ParentId – The Id of the Salesforce record that had its field changed
- Field / Event – The name of the field that was changed
- Old Value – The previous value that was in the field
- New Value – The new value in the field
- Edited By – The user who made the update to the field
- Edit Date – The date the field value was edited
Troubleshooting and auditing your security settings is much easier when field history tracking is enabled. For example, if you’re trying to understand why a specific record owner was updated you can view the record in question to see which user changed the owner and on what date. Additionally, the history reports can be used to see how users are interacting with data, and if there needs to be further field security or validation.
Perhaps a user is consistently incorrectly entering data, the field history tracking can help identify where further training may be needed to keep your data clean. It can also be helpful in terms of monitoring automated processes. If it looks like your system administrator changed the name of every opportunity in your system at 2:00 am, and within a 5-minute time span, chances are there is an automated process running under their name.
To get started with field history tracking, try out the Trailhead Enable Account Field History Tracking for practice.
Tip 2: Beware of the Shared License
One of the scariest things we have come across in regards to data security is a shared user license. For Salesforce, each license should be only accessed by one user. This makes sure that each user is accountable for keeping the data clean and secure. If you have to track down a change made by “Intern Team”, and five different people log in as that user, you have a long day ahead of you!
All of Salesforce’s security features can be locked down by users and profile. Additionally, access can be given to individual users through permission sets. Not to mention, Salesforce generously grants 10 licenses to qualifying nonprofit organizations and allowing multiple users to share a license actually violates the terms of service for the granted licenses. That’s terrifying! So instead of jeopardizing both your security and free licenses, we highly suggest you stick to one user per license.
Tip 3: Embrace Organization-Wide Defaults and Global Sharing Rules
The organization-wide defaults (OWD) define access to all records, whether they can be accessed by anyone or if the records are private for the person who created them. The organization-wide defaults can be updated for each object individually. These are a great place for an admin to start by reviewing and then adjusting to set baseline security defaults. Best practice when thinking about OWDs is to picture the most restricted person who has access to your system, such as an intern. Should they have access to all Opportunities? Should they be able to edit Contact records that are owned by other people?
Once you have the beginning guidelines of the security access to each object, you give further access to Public Groups or Roles through individual sharing rules. For example, if the Opportunity object organization-wide sharing default is set to Private so that each user could only see their opportunities, you could create an individual sharing rule to extend access to record for members of a public group. Therefore, your intern still cannot see any Opportunities, but the Sales Managers can, through Role Hierarchy, and the Finance team can be granted access though sharing rules
The Define Sharing Rules Trailhead is a great place to start regarding Sharing Rules.
Tip 4: Understanding the Differences Between Roles and Profiles
Once you have the baseline organization-wide defaults set up, you can utilize profiles and/or roles to change data access for groups of individuals. Each Salesforce user is required to be assigned a profile, which defines access to objects and fields, as well as other system permissions in the org.
On the other hand, roles were designed to increase data access for specific users. Sharing rules can be used with roles to extend the access of the organization-wide defaults. The role hierarchy helps with defining the data visibility and unlike a profile, defining a role hierarchy is not mandatory.
Essentially, a Profile is what you can do and a Role is what you can see. Thinking about our intern again, his profile of “Data Intern” gives him edit access to opportunities, and because of our organization-wide defaults, he can only see and edit the opportunities he’s created. With the Role Hierarchy, his manager (who we have assigned the “Intern Manager” role) can see ALL of the opportunities that have been created by the members below her. However, Intern Manager’s Profile of Data Manager, does not allow edit access to Opportunities. So, she can see all of her teams opportunities, but she cannot edit them.
Tip 5: A Scheduled Data Export — Your “Just–in–Case”
For long-term data security, it doesn’t hurt to be prepared with a scheduled weekly backup data export. Whether you need to export to another database system, or there is a “worst-case-scenario” situation, it’s best-practices to have a regularly-scheduled backup data export to reference if needed. If your intern got a little too excited with his Opportunity Delete permission, we can grab the data from your most recent export.
From the Setup menu, select “Data Export” and then “Schedule Export” where you can choose the interval that you want your data sent to you. When the backup data export file has been prepared, an email is sent to the specified Salesforce user to download. Make sure you put it on a secure server so that it can be referenced again, as needed.
Bringing it all Together
There are many other ways that you can ensure that your Salesforce data is safe and secure. From guarding objects and fields via the profile and org-wide defaults, to tracking changes to data with the field history tracking. Embracing these security tricks will assure that your organization’s data is safe and secure.
To learn more about data security we recommend you continue to explore Trailhead. If you believe your team needs more support, please do not hesitate to reach out and learn more about how our Managed Services team can assist your organization.
You may also enjoy: