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

Architecturecustom-objectdesignstandard-objects

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.

Best Answer

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.

Related Topic