What is the downside to using a custom object instead of Contact for people-based data?

I am working on coaching application for a client and the coaches (Contacts in the current system) are portal users who need to save information about their customers.

So my plan was to make customers a custom object, making the data available to all portal users and keeping it distinct from the coaches themselves.

I know there are a few specific things that you can only do with Contact records:

  • Send mass emails to Contacts
  • Convert Leads into Contacts

Is there any other thing that you can only do with contact records?


Here is a compendium list (feel free others to contribute!) of advantages / disadvantages to using a custom Object instead of the standard Contact object:


  • Data Model freedom: there are various restrictions on how you can related Standard Objects such as Contact to other objects. For instance, you cannot make Contact a Detail of a custom Master record — Contacts can only be lookups. This, in turn, forces you to use Triggers to replicate the functionality that Roll-up Summary fields could provide if you were able to have a custom Master record of Contact (e.g. in your scenario ‘Team_c’ could be a Master object and ‘Coach_c’ could be the detail. This is not possible with Contacts/Accounts)
  • You escape the subtle, often frustrating linkages between the Account and Contact objects, e.g. the AccountId field, which always has to be populated (even if it’s with the mysterious 001000000000AAA Account), in order for Contact records to be shared with users other than the owner (without enabling View/Modify All Data on a non-Admin User’s Profile). Moreover, Contacts associated with an Account are always implicitly shared to Users who have access to the Account, which can be undesirable if you’re trying to use Contacts in a non-standard way.
  • Standard objects like Contact do not support Apex Managed Sharing — probably not a big deal in your situation, but for ISV vendors this can be a real pain, forcing you to use “Shadow” Share objects to manage complex record-sharing scenarios.
  • You avoid certain License restrictions, e.g. as Peter Knolle mentioned the High Volume Customer Portal license can only CRU, but not Delete, Contact records. With Custom Objects, you have complete freedom over what Portal or Force.com Site users can do as far as Object/Field Permissions.
  • Users with a Salesforce Community License can add Attachments to Custom Objects. Community Licenses don’t let you add Attachments to certain standard objects, including Contact.


  • Only Leads and Contacts can be the targets of the “Who” (WhoId) field on Salesforce Activity records (Tasks and Events)
  • Email Templates, Programmatic Email messaging, and Workflow Email Messaging work very well with Leads and Contacts, not so well with Custom Objects. For instance, using Apex to set the related “person” on a Messaging.SingleEmailMessage requires use of the setTargetObjectId() method, which expects a Lead, User, or Contact Id — custom objects are not supported. Similar difficulties crop up with Workflow Email messaging.
  • You can’t use the Social Contacts feature.
  • You can’t use some built-in Salesforce objects that relate to Contacts, e.g. AccountContactRole, OpportunityContactRole
  • Customer Portal functionality: Portal “Users” can be created easily from a Contact, as this is what Salesforce “expects” you to do. It’s more work to create them from Custom Objects.
  • As Peter Knolle has indicated, many AppExchange apps include functionality that builds off of standard objects, particularly the Contact and Account objects, so by migrating away from using the Contact object you would be limiting which apps you can use. Of course you in some cases you can build your own objects to match these, but this may chew through your objects limits (not to mention development time). Some examples of helpful apps that tie in to Contacts include:
    • Duplicate Prevention utilities
    • Nonprofit Template features, such as Relationships (Contact-to-Contact join) and Affiliations (Account-to-Contact join).
  • You use up one of your Custom Objects. Can be a big deal in Group / Professional Edition.
  • Address fields. Moving away from Contact, you may have to recreate the Salesforce Mailing/Other Address field functionality, which is difficult to replicate exactly.
  • You remove yourself from the standard CRM Lead-to-Account/Contact/Opportunity conversion process. Can be a breath of fresh air if this is what you’re looking for, or a hassle.

Source : Link , Question Author : Keith Mancuso , Answer Author : zachelrath

Leave a Comment