Context: My understanding is that historically Salesforce was built to manage Business-to-Business (B2B) contacts, and the idea that the data model would not be built for contacts without accounts makes sense; meaning semantically viewing a business as an account makes sense, at least to me - and people do business with people through businesses.

Issue: That said, clearly some domains are not naturally built on the concept of requiring a contact to have an account - and Salesforce is no longer just used to manage B2B contacts.

Is there a existing natural way to deal with contacts without accounts that would not require custom fields, reports, etc?

Reason I ask is because currently, it appears that aside from resulting in a somewhat awkward rendering of data, reports, etc. -- forcing individuals to have accounts is currently doubling data usage per entities that are individuals.

  • If you can't use Person Accounts, one option for B2C is to model "Household Accounts" (e.g., the consumers Joe Smith and wife Jane Smith would be Contacts on the same Account), but it usually just ends up being one Contact per Account anyway. – Peter Knolle Apr 2 '14 at 22:13
  • @Peter Knolle: My experience is that there's no use in creating or logging household members; meaning if it is a couple, just edit the fields to treat the "person" as a couple; yes, it's possible they'll stopping being a couple for some reason, though based on my experience, unlikely that can't be addressed at the time it happens. – blunders Apr 2 '14 at 22:45

Your understanding is correct; SFDC unashamedly assumes you're using a standard Sales-y workflow with Accounts and Contacts.

I'm not sure there's a really good alternative here. Some options might be:

  • You could use a single master Account record with all of your Contacts as children. However this breaks down at volume (100k+ records).

  • Person Accounts. Here be dragons. Do not tread here if you can possibly avoid it.

  • A custom object. This gives you a great deal of flexibility but unfortunately means you can't use certain standard functionality that depends on the Contact record or whoId (mail merges, tasks, etc)

| improve this answer | |

Is there a existing natural way to deal with contacts without accounts that would not require custom fields, reports, etc?

@Jonathon Hersh is spot on with his answer regarding how Salesforce is designed to work. That being said, there are some "creative workarounds" for various situations that are possible.

If you have certain "types" of contacts that don't need accounts associated with them, why not create a RecordType and assign all of them to the same "dummy account"? A client I work with does this for all of the individual contractors they use that aren't customer accounts or paid through their normal accounts receivables. You could easily create a variety of different RecordTypes for different types of contacts with each RecordType automatically being assigned to a single account you've set up for that type.

With the new Actions Feature, something like this should be extremely easy to implement and user friendly since the Account and other details would already have the majority of the fields filled-in for users.

| improve this answer | |
  • Assigning contacts to a "dummy account," as @Jonathan Hersh says, breaks down at 100k people per account. So if you promise that your business will never grow, you can go that route. But why would you? As for the Actions feature, ignore that because your question is about database design and not the mechanism for filling that design - solve the first problem first. – DavidSchach Apr 3 '14 at 0:48
  • @blunders didn't say how large he expected his contacts to grow. One could always create an additional RecordType when the Account begins to reach 100k people, etc, etc. The point being, while SF is designed to be B2B, blunders asked if there was a "natural way" of working around the limitation. I provided an answer with a methodology that went beyond Johnathon's excellent response. – crmprogdev Apr 3 '14 at 2:18
  • A separate record type would not combat data skew. I understand the methodology you're proposing, but it is not a best-practice and should not be followed if any other method would work as well. – DavidSchach Apr 3 '14 at 5:43
  • Thank you for the enlightenment. I hold no claim to having any database optimization expertise. I know that I'd never recommend this solution as a means of storing a great number of records. I'd think an org that required in excess of 100k records, really should be enabling person accounts unless there's a compelling reason not to. – crmprogdev Apr 3 '14 at 11:08
  • 1
    The compelling reason not to is that Person Accounts are a hack held together with duct tape. :) – Jonathan Hersh Apr 3 '14 at 15:50

Person accounts are definitely the way to go on this and have been purposely designed for this B2C model (also works great with B2B).

Here are a couple blogs I wrote on the subject:

It should be noted that a lot of the concerns / issues with Person Accounts are no longer an issue and are an artifact from when the model was first released. Salesforce is still improving Person Accounts including an update in Summer 16.

We have been using them for years without issues / limitations.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.