Salesforce CRM allows the users to handle their customer database efficiently by helping them store, process, track and analyze the important details pertaining to their present, potential and past customers.
Salesforce consists of multiple platforms, tools and components, each serving a specific purpose. Though the primary motive of the CRM platform is to simplify the activities performed by the marketing and sales teams of an organisation, the platform itself is fairly complicated to understand. It is very important for Salesforce Developers, Administrators and operators to be careful and precise while implementing the platform for their client organisation. It is therefore important to undertake periodic inspection of Salesforce and its various tools and platforms to ensure smooth functioning of the same. This can be carried out by the means of Salesforce Audit.
What Is Salesforce Health Check Audit ?
Salesforce audit is the process of conducting a thorough inspection of the platform as a whole or of specific tools pertaining to the platform. Just like a financial audit, Salesforce audit is undertaken to ensure seamless and efficient functioning of the system and take preventive measures for the issues (if any). The process of Salesforce Auditing helps users in ascertaining useful information about the CRM platform and diagnosing the real potential of the same. Every system equipped with Salesforce provides its udders with Auditing Features, but they do not secure the platform by themselves. Organisations need to hire qualified Salesforce Auditors for performing specific auditing functions.
An auditor can also be referred to as a Salesforce org doctor or a Salesforce org health check scanner, who conducts thorough inspection and suggests corrective measures to improve the functionality of the platform.
Periodic audits are necessary for a thorough Salesforce health check-up, ensuring that your system is secure and to monitor unforeseen changes and trends in the usability of the platform. However, performing Salesforce Audit is not as easy as it sounds. There are several specific aspects one needs to consider before going ahead with the audit..
Record Modification Fields
The platform of Salesforce allows users to store and track valuable customer information by recording it in tablets of information called Salesforce objects. You can establish specific relationships between these objects such as leads, Accounts, cases, contacts, opportunities etc to carry out the required business processes.
These objects contain multiple records that are created by users for handling the customers/clients on an individual basis. Salesforce objects also contain various fields that contain data pertaining to the name of users who created specific records and the name of users that modified those records. This information forms a fundamental base for undertaking a Salesforce Audit Now.
Monitoring Login History
One of the fundamental processes involved in Salesforce Auditing is that of keeping a track of its login history. The platform allows you in ascertaining and reviewing a list of all the successful and failed login attempts onto the system. This data is critical for the audit as it helps the auditor in reviewing the security of your system.
Salesforce Health Check Tool allows you to track its login history up to a period of six months.
Field History Tracking Salesforce
One of the Salesforce Health Check Best Practices when it comes to auditing is that of tracking its field history. Salesforce health checker can view and track history pertaining to specific Salesforce objects, the data for which is retained for a period up to 18 months through your organisation and up to 24 months if you use an API.
You can track the field history of all the custom Salesforce objects and the following standard objects:
- Order Products
- Price Book Entries
- Contract Line Items
- Service Contracts
Whenever you make any changes in the fields pertaining to the above mentioned Salesforce objects, an entry is added into the History related list. These entries are generally regarding the date a change was made, the time when it was made, the nature of the change and the name of the user who made the change. However, it is important to understand that every field type is not available for reporting these historical trends.
Here are some of the major considerations to keep in mind while undertaking Field History Tracking Salesforce for a thorough Salesforce Audit:
- In case you want to retrieve field history tracking salesforce that falling under the time period of 18 and 24 months, you should use the Data Loader or queryAll() API to do the same.
- All the changes made to fields having more than 255 characters are considered to be edited. The system will not allow you to record their old and new values.
- The field values tracked by a user are displayed in the language in which they were created and are not translated automatically for the concerned user.
- If you are making changes in the custom field labels that are translated using the Translation Workbench, they will be displayed in the location of the user who is viewing the History related list.
- If a trigger makes any change to the Salesforce object you have no permission to edit, the change to that field will not be tracked by the system.
- The changes made to the time fields are not tracked in the related list of field history.
Free Salesforce Audit Trail
Field Salesforce Audit Trail is a component that allows the users to ascertain a specific policy for retaining the archived data pertaining to a field history up to a period of 10 years from the time when the data was archived. With the help of this component, you can undertake Salesforce audit in compliance with the industry regulations regarding retention of Salesforce data and your audit capability.
Through Field Audit Trial, you can use Salesforce Metadata API for defining a retention policy for the concerned field history, provided that the fields have the option of field history tracking salesforce enabled. Following this, you can work with the archived Salesforce data with the help of SOAP API, REST API and Tooling API.
When you use Field Audit Trail, your field history is copied from the History related list to the big object of “Field History Archive”. You start by defining one “History Retention Policy” for your related lists to specify the Field Salesforce Audit Trail retention policies for the Salesforce objects you want to archive. After you have defined the policy, use Metadata API for deploying the concerned big object.
Field Audit Trail allows you to track a maximum of 60 fields for every Salesforce object. Without this feature, you can track a mere 20 fields per Salesforce object. Also, you can retain archived data pertaining to your field history for a period of 10 years with Field Audit Trail, as opposed to 18 months without using this feature.
You can define field retention policies for all standard Salesforce objects whose field history can be tracked and all the custom Salesforce objects having field tracking history enabled. You can also include the policies pertaining to field retention in the form of managed and unmanaged packages.
However, not all fields can be tracked using this feature. Here are the fields you cannot track with the help of Field Audit Trail:
- Roll-up summary, auto-number or formula fields
- “Created By” and “Last Modified By” fields
- Expected Revenue fields (on the object of Opportunities)
- Master Solution Title or Master Solution Details
- Multi-select fields
- Long text fields