8

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.

2
  • 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. Apr 2, 2014 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, 2014 at 22:45

4 Answers 4

10

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)

2

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.

8
  • 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. Apr 3, 2014 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, 2014 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. Apr 3, 2014 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, 2014 at 11:08
  • 1
    The compelling reason not to is that Person Accounts are a hack held together with duct tape. :) Apr 3, 2014 at 15:50
1

Actually, you MAY HAVE contacts without accounts. However, you can create them only programmatically, via APEX or API. You cannot create such a contact from a Standard UI and if you created a contact without an account via APEX, you will not be able to edit it from a Standard Salesforce UI unless specifying an Account on it.

So the natural way to deal with contacts without accounts is to override standard UI with custom UI which will not require Account field being populated.

There are certain implications of this, like:

Currently the system will mark any contacts without accounts as 'Private', so only the owner can see them. This can be overcome with "View All" and "Modify All" permissions, however, this workaround also blows away any other security measures that are in place.

A contact that isn’t linked to an account is always private, regardless of your organization’s sharing model. Only the owner of the contact and administrators can view it. Sharing rules and workflow rules don’t apply to private contacts. If your organization uses divisions, private contacts always belong to the global division.

0

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.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .