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.

  • 1
    Part of your solution here is setting you up to violate the Master Service Agreement and the Partner Program Agreement, you shouldn't pursue this path for distribution of the application. Reference for much more detail: salesforce.stackexchange.com/a/268118/660
    – Mark Pond
    Nov 8, 2021 at 21:14

2 Answers 2


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.

  • 2
    Also, if you were to decide to go the OEM route, you would suffer additional limitations compared to other license types. Granted, I don't think there's that many OEMs out there, but it's good to know that can be a deciding factor.
    – sfdcfox
    Nov 8, 2021 at 22:39
  • Appropriate permissions sets and profiles along with sharing rules can control access to standard objects, though there may be competing needs between standard functionality and custom functionality.
    – Phil W
    Nov 9, 2021 at 7:38
  • For me, it is essential that a "custom use" of a standard object still aligns with the true meaning of that object - this is my extrapolation on what you say around "intended way". Using a standard object (e.g. Contact to represent a person of some kind) can make your package work well with other packages that do likewise and thus reduce integration costs and simplify deployments.
    – Phil W
    Nov 9, 2021 at 7:43
  • Beware of limits around numbers of custom fields and cross-object formulae too. One of the advantages of using a custom object of your own is that it is less likely to have many other fields added to it by other packages compared with standard objects.
    – Phil W
    Nov 9, 2021 at 7:47
  • @PhilW your point about standard Fields it's weird, because I tried adding some Event standard fields to Managed Permission Sets and in resulting Package this fields were removed
    – ytiq
    Nov 9, 2021 at 13:17

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.