0

I have been searching on the Internet for the disadvantage of using account Object. I am new to SF. I recently developed a system using custom object. Now, one of the developer asked me, Why i did not use Account object. I thought of using account object but because Account object have too many fields, I didn't use it and created my own object.

The whole internet is against Custom Objects.

Can anyone give me some references or some points on why Account (Standard) object should not be used and custom Object should be preferred?

closed as primarily opinion-based by Raul, Oleksandr Berehovskyi, glls, battery.cord, Himanshu Jan 11 '18 at 15:05

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

1

Here are some reasons to consider custom objects over standard objects for a particular solution:

  1. Standard objects are shared between all apps using them - if you have 3 or 4 apps using the same standard object, you end up with a lot of record types and a lot of extra fields that are only used by one app but are present for all of them. Note that this can also be confusing for any users of more than one app, where they have to have access create with record types from both apps - when creating an Account on one, they will be presented with record type options from the other.
  2. Standard objects often have odd rules that you may not discover until after you've started using them and it is too late to change. CampaignMembers cannot be reparented and there is no way to change that, for example.
  3. Using an object just because it is standard leads to naming confusion. If you have a need to store information that doesn't obviously fit the intended use of a standard object, you should strongly consider using a custom object for it to avoid confusion. Since you are stuck with the label for the name for tabs (e.g. the Account tab is always called "Accounts"), even if you are using the standard object "correctly" your customer may be used to having the data it's holding being labelled differently, and changing the label changes it for every app using it.
  4. Standard objects may have fields required which you do not need, and even worse may force you to put fields on standard layouts (Account Parent comes to mind for the second part).
  5. This is related to 1, compartmentalizing your data into different objects makes data maintenance easier, since you know all the data you are retrieving from an object actually has to do with its purpose. If you have multiple apps storing data in the same object, you have to make sure to filter by record type, and hope none of the records were mislabelled. Additionally, separating the data avoids having a bug from one app viewing or performing DML on data from another.
  6. Standard objects aren't always supported by platform features that support custom objects. The Data Import Wizard, for example, only supports accounts, contacts, leads, solutions, person accounts, or articles, while supporting any custom object.
  • 1
    Also, you cannot use Apex Managed Sharing with standard objects. – David Reed Jan 11 '18 at 15:17