Salesforce Best Practices – Contact Object

Share this article...

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.

5 thoughts on “Salesforce Best Practices – Contact Object

  1. We come across a lot of contacts with vendors from the appexchange and would it be bad practice to place those type of contacts in salesforce under a different record type? Internal employees will need access to them depending if its their accounts payable department, account executive, etc.

  2. Per your statement “Phone numbers and email addresses are unique worldwide”. We find a lot of people at the same office, have the same phone number. How can you link these people together without creating a new Account?

  3. In a single org environment, spanning multiple lines of business (State government), we have contacts which will interact with multiple business apps on our platform. Their role may change depending on which LOB they are interacting with at any given time. An example; Suzy Vermonter is a foster mom and may wish to access/review the stipend she receives for providing foster care in her home (she is providing services on behalf of the state), Suzy also has her own child receiving services/case management through the child development division. Suzy works part time for the state answering and logging calls In SalesForce from the public about potential child abuse situations. Suzy also has a complaint she wishes to submit via the governors constituent management portal. Lastly Suzy may use different contact information depending on which service or provider role she is accessing.
    In this scenario, a contact could have multiple roles. Is it possible to assign different roles to the same contact depending on the interaction/service occurring? I.e. service partner provider, employee guardian, constituent, client/customer etc. further, how would you recommend any changes to the contact record be governed (who owns the contact record and can edit it?. and how would the concept of multiple addresses or emails be managed?
    Any guidance would be greatly appreciated!

Add Comment