I would like to create a custom app package that provides the user with a setup interface in which they can input their own preferences, which inputs will then be referenced by apex code. I will be using VisualForce to create the page, of course.

For example, I would like the user to be able to specify a user in a lookup field, and whoever they specify will be assigned certain records (this logic is part of the apex class, just need to plug in the user ID). They will also specify picklist values that represent standard object fields so that these fields are plugged into logical statements in the apex code. My goal is to have much of the code be taylored to the end user by user input via this setup page.

Here is the key question I keep circling back to: what is the best way to store the user inputs in the system so they can be referenced by the code? I only know of two ways to do this: custom object and custom settings, but neither is a perfect solution. Custom settings are too limited given the available field types (i.e. no picklists, no lookups). With a custom object I would need to make it so the first time the setup page is configured, it inserts a custom object record (or can I insert the record initially as part of the package installation...?), that is then updated by subsequent updates to the setup page. This feels messy and I don't want my users to be able to access the record directly (though if this is the only way I would like to know any best practices I should be aware of). Also, I would prefer not to have to rely on a specific record that needs to be queried to store this key setup information, but would rather have a more global and static method of doing so.

Are there any suggestions or best practices for this type of custom setup page that someone can please help guide me with?

Thanks! Brent

2 Answers 2


We had similar requirement and we opted custom settings over custom object.There are known advantages of using custom setting over custom object. From Salesforce documentation: Custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database.This data can then be used by formula fields, validation rules, flows, Apex, and the SOAP API.

The drawback of less number of available datatype can be handled by your setup visualforce page.For example you can show a pick list to user on user-interface and store value in text field. Similarly bind some other lookup field on user interface and before save assign value to custom setting object field.

At the time we developed this solution Custom Metadata Types were not available.At present, I feel Custom Metadata Types are more close to your requirement as they are deployable and are flexible to be used in managed packages.

I hope that helps.

  • Mukesh Verma, thank you for the response. Custom mdt looks perfect except that it can't be updated via apex, so my VF page wouldn't function properly. Custom settings do look great for the reasons you described, and your workaround for picklists sounds great, but my only problem is that they don't have lookup fields. I could store the object ids in a text field, but I would need the front end VF fields to look, feel and behave like lookups. Is this possible? May 22, 2016 at 1:08
  • By the way, updating mdts via apex is an idea you can vote up here: success.salesforce.com/ideaView?id=08730000000l4TkAAI I think this will be extremely valuable. May 22, 2016 at 1:21
  • Again a workaround. You can mock up lookup fields as well if you have some similar lookup field in any other object. Suppose you want to have a lookup for User and object X have some userlookup field for Manager. Now you can bind this lookup field on your VF and before saving custom setting record assign binded field to text field. May 22, 2016 at 4:09
  • That makes sense, thank you so much Mukesh! Very clever idea. May 28, 2016 at 2:08

I have read it several times but still i need more clarification. So far it is looking that the best approach for you to have records in custom object because custom objects provides way too much flexibility in terms of different types of fields and so on.

  • Then first time when you install the package you can insert records in that using PostInstallHandler.

  • You can hide object from layout so that nobody can access the records of it directly.

  • One more way to pass records is through the use of Custom metadata type but that depends upon your exact needs.


To hide the custom object you should not pass the layout and tab of that custom object with manage package.Although if someone intentionally want to create custom tab they can create it in there org. Or if you are passing the profile with your package you can select tab hidden option for your custom object.

Reasons of choosing Custom object:

1.As Mukesh Verma has already pointed out some advantages of custom setting.There is one more that you can use protected custom setting to hide it from user but any point if you would require to debug anything on client side you will be helpless in that case.

2.If you are using standard controllers then there will be very less effort required in terms of validations.You can directly use several features like save, edit etc of standard controllers.

3.If you are going to have large number of records then there are certain limits with custom setting.

4.One last thing which bothers me most about custom setting is they require Customize Application permission to manage, create, edit, and delete custom settings.If any point you need to perform any operation through API this could be a big issue for you.

So all in all it fairly depends upon your requirements and you can choose according to that.

  • Mr. Frodo, your feedback is greatly appreciated. It looks like custom mdt is a great solution except SFDC doesn't currently allow updates of mdt records via apex, and so my VF page wouldn't function properly when plugged into this record (and I just tried, inputFields don't even show as editable in VF). It seems currently custom object is the way to go, simply because it has lookup fields and can be edited in apex. Regarding your point #2, how can I hide the behind-the-scenes object and its associated record from the user who installs our app? May 22, 2016 at 1:03
  • By the way, updating mdts via apex is an idea you can vote up here: success.salesforce.com/ideaView?id=08730000000l4TkAAI I think this will be extremely valuable. May 22, 2016 at 1:20
  • I have updated my answer with more information and yes i'm going to support this idea this would be really helpful.
    – Mr.Frodo
    May 22, 2016 at 5:59

You must log in to answer this question.

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