Design Considerations - When to use a custom object vs standard object

Question

I am creating a salesforce unlocked package that I want to get out on the app exchange. The package is for a company that wants to insert and update records with product usage data.

They want to send data into salesforce to see how Accounts and Contacts are using their specific product.

Account Product Data includes:

• Number of Users

• Number of Logins this Week

• Number of Logins Trailing 30 days

• Features Being used

Contact Product User Data includes:

• Last Login

• Number of Times Logged in

• Number of times logged in Trailing 30 days

I wanted to tell them to avoid custom objects and use campaigns where the campaign would represent the account product data and the campaign members would represent the product users. I said this because many tools naturally read off the campaign object and much of the SFDC standard functionalities would not need to be replicated such as tying campaigns to Opportunities.

Another aspect that the company was asking for was to ensure they could see a time series on the accounts product usage performance. For that I said to created Tasks. Tasks are naturally the standard objects that create time series against leads and contacts.

Overall, I want to really know what questions I should be asking myself and the design partners as I consider custom objects vs standard objects.

Answer 1

First thing. If you want to distribute your solution on AppExchange, then you need Managed Package (i.e. Locked Package), because Unlocked Packages are not supported for AppExchange.

There is nothing bad with using Standard Objects in your package, but you need to consider what are your target customers because there are a lot of different types of orgs with different features.

If you want to give your solution only to customers who have enabled Campaigns and Campaign Members, then sure you can use it. Not all org types support Campaigns.

Another point to consider is that, do you use standard functionality in any not intended way. Because customers can have already existing functionality on Standard Objects, then you can potentially either break their functionality or their functionality can prevent your solution from working properly.

Also, if you use Standard Fields or Objects then you can't control access to them in your custom Profiles or Permission Sets, so you'll rely on your customers to properly configure access to the functionality you potentially using.

So to summarize, sometimes it's just simpler to create a Custom Object to make sure that you have full control, support, and stability unless you think that your support of Standard Functionality is a key selling point.

Hopefully, I provided some food for thought for you and it'll help you to make a decision.

Answer 2

Wanting to add to the points in the answer by @ytiq, there are some further considerations:

1. Using cloned/custom profiles, permission sets and sharing rules allows full control over standard and custom objects available in the org. Obviously admins can choose to create profiles/perm sets that expose whatever they want and it isn't currently possible for a package to have "protected" objects or fields (unlike protected settings and custom metadata types/custom metadata type records, which do exist and which are only visible within the package itself).
2. It is absolutely essential that any "custom" use made of a standard object is fully in line with the true meaning of that object. For example, it would make no sense to extend Contact and treat it as a task to be performed, but it would be fine to extend Contact where that extension adds something that relates to it as a "person".
3. Using a standard object, correctly aligned with the original meaning of that object, in your package can make integrating your package with other packages that also use that standard object much easier, reduce costs, simplify deployments and reduce data input/maintenance burdens.
4. There are limits on numbers of custom fields that can be added to an object, and even tighter limits around the number of cross-object relationships that can be used in custom formula fields on an object. An advantage of using a custom object is that these limits are all yours and you need not worry about third-parties having already used too many of these (and therefore preventing your package from installing).