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

Question

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?

Answer 1

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

Advantages:

• 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.

Disadvantages:

• 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.

Answer 2

So, this is probably obvious to you based on your plan, but if any of those customers need to become portal users at some point you can create a portal user from a contact.

The other thing that I can see in your application is that if you use a contact you can use AccountContactRoles or OpportunityContactRoles records to denote role(s) that the contact is playing on the Account or Opportunities.

Any contact related AppExchange Apps would be able to be used and you could benefit from any future/TBD contact functionality.

Make sure that you understand the User License Type that you are using. For example, according to the documentation the high volume customer portal license user only has Create, Read, and Edit permissions on the Contact object. If you use a custom object you can give them whatever permissions you want.

Answer 3

The big one for me would be the lack of access to Campaigns, and that you can't use the Add to Campaigns button on reports for Contacts to add then to Campaigns - so if you want to use Campaigns for lists, events etc, you can't just run a report and click a button - you would have to create the Campaign functionality and the ability to mass add people to it.

If that is something you envision needing, I would consider using record types on Contact to differentiate the different contact types...

Answer 4

I noticed "Person Accounts" haven't been brought up as an alternative. Anyone have any experience in using them? I'd like to hear your feedback. Currently Person Accounts is the composite equivalent of Contact for B2C scenarios.

Answer 5

Thanks for all the feedback everyone. If i was going to make all our coaches customers as contacts then the coaches themselves would need to have Enterprise Admin Portal Account (not Service Cloud) because Service Cloud can only access their own contact record not ones they create, right?

As with any setup cost is a big factor so that alone might be the reason to stick with Service Cloud and let all the customers be a custom object