3

Background information to my question:

  • I am about to deploy a new release of a Salesforce Service Cloud solution to a customer
  • The customer primarily utilizes the solution for B2C purposes
  • In the release that is being used by my customer, there are 100.000+ cases and 50.000+ contacts
  • In the first release of the solution, only Cases and Contacts were used. In second release, I am introducing Accounts
  • In the first release, we relied on a Public data model. In the new release we are converting to a Private Data Model. Because of the new Private Data Model, I have to somehow assign all contacts to an account.
  • I am aware that Salesforce suggests solving this problem by converting into Person Accounts, but because it is such an extensive change (permanent change), which would have so many complications for my customer, I am thinking of following an alternative approach: creating a new account called "No account", which I will assign all 50.000+ contacts to.

And here comes my questions:

  1. What are your general thoughts on the above?
  2. What do you think about my alternative approach?
  3. Could any issues arise from so having so many contacts related to the same account?
  4. What are pros and cons of following my suggested alternative approach VS. converting to person Accounts?
  5. Can you think about any additional approaches to address this problem? For instance, would it be better to just create a new custom object that replicates some of the functionality of the standard Account-object/layout, etc.
1
  • What complications do you see using Person Accounts?
    – sfdcFanBoy
    Jun 28, 2016 at 2:39

1 Answer 1

2

Using Person Accounts should be regarded as a last choice. Person Accounts are not supported in the Lightning Experience (at the time of this answer), and are generally the last type of object to get supported for any new feature (I remember when Outlook didn't support them either). While they are neat conceptually, they seem sort of like that youngest child that always gets the hand-me-downs because there's no more resources to go around. Until that changes, I'd recommend you avoid using this feature (if they ever get to that point).

Using a single account called "no account" or some other moniker is also not advised. Sharing is difficult to get right when all contacts are owned by a single account, and this also affects opportunity and case sharing. You may not care about these today, but it's likely you will in the future. Furthermore, salesforce can behave poorly when (almost) every single record in the system is related to a single parent record. Notably, you'd need to enable "Load Related Lists Separately" or you'll find that the master account will take a very indecent amount of time to load its detail page. In fact, we recently turned on that feature because of how we store assets (which are things we sell to customers, each with a serial number), and the accounts that housed that data would take a minute or longer to load without this feature enabled.

Creating custom objects to handle this design also hinders your system considerably, because you'll find that you can't email custom objects, and many features depend on using accounts and/or contacts, like Salesforce for Outlook, and almost every AppExchange app on the market that deals with addresses, inventory, lead generation, and so on. It's simply a nightmare to try and go against the grain.

Instead, I'd suggest you turn to the major sector that's already using a primarily B2C model in salesforce: Not-For-Profit organizations. You might try installing the Nonprofit Starter Pack to see how they do things, but basically they renamed Accounts to "Households" (hint: install this in a Developer Edition or Sandbox Edition first to avoid any surprises). So, you might have a Smith household (account), and John and Jane Smith would be contacts on that household. You'll still need to think about how your sharing is set up, but you'll find things are a lot less complicated when you have a multitude of accounts, the way the system was designed to be. Best of all, if the NFP starter pack isn't your thing, you can always just uninstall it later, unlike Person Accounts, which is non-reversible.

4
  • Very good insightful comments - Just if I didn't make it clear, we're using service cloud. I guess we will not go the "non-profit-starter-pack-way". But I take your point on the enable "Load related lists separately" into account - pun intended. Nov 12, 2015 at 12:16
  • Would you elaborate more on the "single account for all records solution". I mean we actually don't utilize the account related records feature. Atleast not for the dummy account-record-type. I saw a comment on another forum that around 100.000 child records, it will break down. A "not-to-pretty" solution to that would be to create a new dummy account at that time. I guess it would be around once a year then you would have to create a new dummy account-object. What are your thoughts on that? Nov 12, 2015 at 12:16
  • @ChristianCharity Salesforce simply isn't designed to handle a single-account model. You lose the benefits of sharing rule/security settings, it can complicate and/or slow down reporting. At minimum, if you wanted to minimize accounts used would be to assign one account to each user, and assign all records they own to that account; this would keep your security model fairly consistent. Still, simply using one account per every few contacts is still arguably the best way to go about it (NFP model). I've seen many models in action, and that has been the best model so far.
    – sfdcfox
    Nov 12, 2015 at 14:21
  • 1
    @sfdcfox what is your opinion on Person Accounts in 2020?
    – Shanerk
    Feb 19, 2020 at 18:21

You must log in to answer this question.

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