As I have already mentioned in the previous Lead and Account best practice articles, Salesforce standard objects come with a predefined number of features you should make the most of to build scalable solutions.
For the third article of this series, I am listing best practices for the Salesforce contact object:
1. Unique Contacts (Email Addresses or formatted phone numbers)
Setting up duplicate rules will stop users from entering duplicate records in Salesforce. The sooner in the Salesforce process you implement this, the cleaner your database will be. Unless there is a big reason for it, it is best to block the creation of duplicate records in your system. Phone numbers and email addresses are unique worldwide, so you can use them as reliable criteria to identify duplicate records and block them.
If for any reason, you need to resort to displaying warnings when duplicate rules identify a record potentially matching another one in your Salesforce database, I advise you to create a duplicate records report to frequently review the potential matches and merge those records that contain real duplicates. For that, you will have to create a custom report type selecting Account, Contact, Lead, or Duplicate Record Set as the primary object and Duplicate Record Items as the related object.
2. Tag Contacts according to their type
In Salesforce the Account and Contact tables have a one-to-many relationship; for example, as a company can have multiple employees, a Salesforce Account can have multiple Contacts. Among those Contacts, there will certainly be different types and it is very important to categorise them so that you can filter them later on; for instance, to run a specific Report or to add a certain type of contacts to a Campaign.
One way of tagging Contacts is by creating a custom picklist or a multi-picklist field listing the different types of Contacts that are relevant for your business process and by making that field mandatory to ensure all Contacts have a type. Another option is enabling Contact roles to determine the role of a contact in an Account, a Case, an Opportunity or a Contract. Note that Contact Roles allow you to set a different role for the same Contact depending on the record you are relating it to on the Contact Role related list.
3. Contacts vs. Related Contacts (Contacts to multiple accounts)
In point two I have mentioned how the Account and Contact objects have a standard one-to-many relationship that allows an Account to have more than one related Contact. But what happens if I want to relate the same Contact to multiple Accounts? The typical use case for this would be when I need to create a chain made up of a number of Accounts related to a Parent Account and one Contact is related to different Accounts; for example, all the Child Accounts share the same decision maker as the Parent Account. To avoid replicating the same Contact to be able to relate it to more than one Account, I can use the Account Contact Relationship object, with which I can create records where I indicate which Contact is related to which Account.
4. Use Validation Rules to ensure relevant Contact details are provided
Typically, companies using business Contacts do not need to store a lot of information about each Contact, so the list of custom fields in the Contact object should be small. However, it is key that Contact records are clean, as they contain the information, such as phone, email, etc., that we are mainly going to use to get in touch with our business clients. For this reason, validation rules are key to ensure your Contact base is clean and accurate, as storing wrong contact details will have a very negative impact in the efficiency of the different teams that need to contact our clients.
Two examples of validation rules you can use in the Contact object are enforcing a specific phone format, which will help in identifying duplicate phone numbers, and requiring the Contact’s Salutation, which will be very useful if you want to send automated emails from Salesforce at some point and you want to address them using their Salutation and their Last Name.
As you have seen, standard objects help you create very efficient Salesforce process in the simplest way possible, so it is best practice to always try to find a solution with a standard Salesforce functionality before resorting to a custom one. Nevertheless, when standard features are not suitable for a specific process you need to build, you will surely find a custom solution to do so.