What is the best practice to store custom configuration for a managed package application?
Clash Royale CLAN TAG#URR8PPP
We are working on an application in managed package, and we need to store app configuration. Generally, we want to allow users to turn on/off some features in our app. For example, on the settings page (visualforce page) there will be a checkbox "Allow <something>"
that users would use to enable/disable functionality that our app provides.
What we need basically is:
- Have a set of default settings for an application (this should be available right after the app was installed)
- Allow end users (in a subscriber org) change those default settings at any time
So there are quite a few options how we can address this: (1) constants in apex class; (2) custom objects; (3) custom settings; (4) custom metadata types.
While all of these options can get us what we need, Custom Metadata Types seems a better choice. It's newer than Custom Settings, more flexible, and its values can be shipped with application directly, reducing the need apex install scripts to populate values. Still Custom Metadata Types has some limitations, e.g. record values cannot be updated in Apex (or am I wrong here?).
Hence I have several questions:
- This is a high level question concerning design and architecture overall: What is a common approach to store app settings for a managed package application? Are there any design patterns?
- If Custom Metadata Types was our go-for option, how would we update record values? Taking my example above, how would I store the value of
"Allow <something>"
checkbox to the database?
managed-package bestpractice custom-metadata custom-metadata-types
add a comment |
We are working on an application in managed package, and we need to store app configuration. Generally, we want to allow users to turn on/off some features in our app. For example, on the settings page (visualforce page) there will be a checkbox "Allow <something>"
that users would use to enable/disable functionality that our app provides.
What we need basically is:
- Have a set of default settings for an application (this should be available right after the app was installed)
- Allow end users (in a subscriber org) change those default settings at any time
So there are quite a few options how we can address this: (1) constants in apex class; (2) custom objects; (3) custom settings; (4) custom metadata types.
While all of these options can get us what we need, Custom Metadata Types seems a better choice. It's newer than Custom Settings, more flexible, and its values can be shipped with application directly, reducing the need apex install scripts to populate values. Still Custom Metadata Types has some limitations, e.g. record values cannot be updated in Apex (or am I wrong here?).
Hence I have several questions:
- This is a high level question concerning design and architecture overall: What is a common approach to store app settings for a managed package application? Are there any design patterns?
- If Custom Metadata Types was our go-for option, how would we update record values? Taking my example above, how would I store the value of
"Allow <something>"
checkbox to the database?
managed-package bestpractice custom-metadata custom-metadata-types
add a comment |
We are working on an application in managed package, and we need to store app configuration. Generally, we want to allow users to turn on/off some features in our app. For example, on the settings page (visualforce page) there will be a checkbox "Allow <something>"
that users would use to enable/disable functionality that our app provides.
What we need basically is:
- Have a set of default settings for an application (this should be available right after the app was installed)
- Allow end users (in a subscriber org) change those default settings at any time
So there are quite a few options how we can address this: (1) constants in apex class; (2) custom objects; (3) custom settings; (4) custom metadata types.
While all of these options can get us what we need, Custom Metadata Types seems a better choice. It's newer than Custom Settings, more flexible, and its values can be shipped with application directly, reducing the need apex install scripts to populate values. Still Custom Metadata Types has some limitations, e.g. record values cannot be updated in Apex (or am I wrong here?).
Hence I have several questions:
- This is a high level question concerning design and architecture overall: What is a common approach to store app settings for a managed package application? Are there any design patterns?
- If Custom Metadata Types was our go-for option, how would we update record values? Taking my example above, how would I store the value of
"Allow <something>"
checkbox to the database?
managed-package bestpractice custom-metadata custom-metadata-types
We are working on an application in managed package, and we need to store app configuration. Generally, we want to allow users to turn on/off some features in our app. For example, on the settings page (visualforce page) there will be a checkbox "Allow <something>"
that users would use to enable/disable functionality that our app provides.
What we need basically is:
- Have a set of default settings for an application (this should be available right after the app was installed)
- Allow end users (in a subscriber org) change those default settings at any time
So there are quite a few options how we can address this: (1) constants in apex class; (2) custom objects; (3) custom settings; (4) custom metadata types.
While all of these options can get us what we need, Custom Metadata Types seems a better choice. It's newer than Custom Settings, more flexible, and its values can be shipped with application directly, reducing the need apex install scripts to populate values. Still Custom Metadata Types has some limitations, e.g. record values cannot be updated in Apex (or am I wrong here?).
Hence I have several questions:
- This is a high level question concerning design and architecture overall: What is a common approach to store app settings for a managed package application? Are there any design patterns?
- If Custom Metadata Types was our go-for option, how would we update record values? Taking my example above, how would I store the value of
"Allow <something>"
checkbox to the database?
managed-package bestpractice custom-metadata custom-metadata-types
managed-package bestpractice custom-metadata custom-metadata-types
edited Jan 10 at 16:31
Eduard
asked Jan 10 at 10:42
EduardEduard
1,8372622
1,8372622
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
I would pretty much entirely dismiss
- Constants in apex class: It's not possible for the end-users to modify them; they're not good practice anyway)
- Custom objects: Can't ship them, end-users can't deploy them. You're wanting to store metadata and the platform intends you to use Custom Settings or Custom Metadata for that
- (a) List Custom Settings - These days, Custom Metadata is better in almost every way
Which leaves you with
- (b) Hierarchy Custom Setting - Useful because they are per-user, and for storing lots of different settings together. Bad because you can't package the values, and the end-user can't deploy them
- Custom Metadata - the best option if you can make it work. You can package the values, and end-users can deploy them.
The downside of Custom Metadata is that you have to use the Metadata.DeployContainer
and similar classes to write to them from Apex and this has to be done asynchronously. Nevertheless, you can write a Visualforce page, or Lightning Component to make this relatively easy for your end-users.
See https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Metadata_CustomMetadata.htm for details.
2
List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
– sfdcfox
Jan 10 at 15:28
I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
– Aidan
Jan 10 at 16:13
Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
– Eduard
Jan 10 at 17:17
add a comment |
One option missing here is Custom Permissions
For your example, Custom Permissions might be a good fit because it is a boolean enable/disable option. If you want by default to allow a feature, you could have a custom permission called DisableXYZFeature that can be applied via profile or permission set. If each of your custom settings are of this nature, it would also eliminate your need to build a configuration screen, as it would be controlled through the platform's Permission Set and Profile setup screens.
That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
– Eduard
Jan 10 at 17:15
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "459"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f246165%2fwhat-is-the-best-practice-to-store-custom-configuration-for-a-managed-package-ap%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I would pretty much entirely dismiss
- Constants in apex class: It's not possible for the end-users to modify them; they're not good practice anyway)
- Custom objects: Can't ship them, end-users can't deploy them. You're wanting to store metadata and the platform intends you to use Custom Settings or Custom Metadata for that
- (a) List Custom Settings - These days, Custom Metadata is better in almost every way
Which leaves you with
- (b) Hierarchy Custom Setting - Useful because they are per-user, and for storing lots of different settings together. Bad because you can't package the values, and the end-user can't deploy them
- Custom Metadata - the best option if you can make it work. You can package the values, and end-users can deploy them.
The downside of Custom Metadata is that you have to use the Metadata.DeployContainer
and similar classes to write to them from Apex and this has to be done asynchronously. Nevertheless, you can write a Visualforce page, or Lightning Component to make this relatively easy for your end-users.
See https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Metadata_CustomMetadata.htm for details.
2
List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
– sfdcfox
Jan 10 at 15:28
I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
– Aidan
Jan 10 at 16:13
Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
– Eduard
Jan 10 at 17:17
add a comment |
I would pretty much entirely dismiss
- Constants in apex class: It's not possible for the end-users to modify them; they're not good practice anyway)
- Custom objects: Can't ship them, end-users can't deploy them. You're wanting to store metadata and the platform intends you to use Custom Settings or Custom Metadata for that
- (a) List Custom Settings - These days, Custom Metadata is better in almost every way
Which leaves you with
- (b) Hierarchy Custom Setting - Useful because they are per-user, and for storing lots of different settings together. Bad because you can't package the values, and the end-user can't deploy them
- Custom Metadata - the best option if you can make it work. You can package the values, and end-users can deploy them.
The downside of Custom Metadata is that you have to use the Metadata.DeployContainer
and similar classes to write to them from Apex and this has to be done asynchronously. Nevertheless, you can write a Visualforce page, or Lightning Component to make this relatively easy for your end-users.
See https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Metadata_CustomMetadata.htm for details.
2
List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
– sfdcfox
Jan 10 at 15:28
I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
– Aidan
Jan 10 at 16:13
Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
– Eduard
Jan 10 at 17:17
add a comment |
I would pretty much entirely dismiss
- Constants in apex class: It's not possible for the end-users to modify them; they're not good practice anyway)
- Custom objects: Can't ship them, end-users can't deploy them. You're wanting to store metadata and the platform intends you to use Custom Settings or Custom Metadata for that
- (a) List Custom Settings - These days, Custom Metadata is better in almost every way
Which leaves you with
- (b) Hierarchy Custom Setting - Useful because they are per-user, and for storing lots of different settings together. Bad because you can't package the values, and the end-user can't deploy them
- Custom Metadata - the best option if you can make it work. You can package the values, and end-users can deploy them.
The downside of Custom Metadata is that you have to use the Metadata.DeployContainer
and similar classes to write to them from Apex and this has to be done asynchronously. Nevertheless, you can write a Visualforce page, or Lightning Component to make this relatively easy for your end-users.
See https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Metadata_CustomMetadata.htm for details.
I would pretty much entirely dismiss
- Constants in apex class: It's not possible for the end-users to modify them; they're not good practice anyway)
- Custom objects: Can't ship them, end-users can't deploy them. You're wanting to store metadata and the platform intends you to use Custom Settings or Custom Metadata for that
- (a) List Custom Settings - These days, Custom Metadata is better in almost every way
Which leaves you with
- (b) Hierarchy Custom Setting - Useful because they are per-user, and for storing lots of different settings together. Bad because you can't package the values, and the end-user can't deploy them
- Custom Metadata - the best option if you can make it work. You can package the values, and end-users can deploy them.
The downside of Custom Metadata is that you have to use the Metadata.DeployContainer
and similar classes to write to them from Apex and this has to be done asynchronously. Nevertheless, you can write a Visualforce page, or Lightning Component to make this relatively easy for your end-users.
See https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_class_Metadata_CustomMetadata.htm for details.
answered Jan 10 at 11:02
AidanAidan
6,9651043
6,9651043
2
List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
– sfdcfox
Jan 10 at 15:28
I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
– Aidan
Jan 10 at 16:13
Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
– Eduard
Jan 10 at 17:17
add a comment |
2
List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
– sfdcfox
Jan 10 at 15:28
I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
– Aidan
Jan 10 at 16:13
Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
– Eduard
Jan 10 at 17:17
2
2
List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
– sfdcfox
Jan 10 at 15:28
List Custom Settings are actually deprecated. Can't create new ones if you wanted to.
– sfdcfox
Jan 10 at 15:28
I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
– Aidan
Jan 10 at 16:13
I did not know that. Last time I looked, you could create them by jumping through a few hoops, but that's interesting to know - thanks!
– Aidan
Jan 10 at 16:13
Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
– Eduard
Jan 10 at 17:17
Thanks, @Aidan. We Custom Metadata types an obvious candidate here. Still I am curious if there are some common patterns or best practices for implementation of application configuration.
– Eduard
Jan 10 at 17:17
add a comment |
One option missing here is Custom Permissions
For your example, Custom Permissions might be a good fit because it is a boolean enable/disable option. If you want by default to allow a feature, you could have a custom permission called DisableXYZFeature that can be applied via profile or permission set. If each of your custom settings are of this nature, it would also eliminate your need to build a configuration screen, as it would be controlled through the platform's Permission Set and Profile setup screens.
That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
– Eduard
Jan 10 at 17:15
add a comment |
One option missing here is Custom Permissions
For your example, Custom Permissions might be a good fit because it is a boolean enable/disable option. If you want by default to allow a feature, you could have a custom permission called DisableXYZFeature that can be applied via profile or permission set. If each of your custom settings are of this nature, it would also eliminate your need to build a configuration screen, as it would be controlled through the platform's Permission Set and Profile setup screens.
That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
– Eduard
Jan 10 at 17:15
add a comment |
One option missing here is Custom Permissions
For your example, Custom Permissions might be a good fit because it is a boolean enable/disable option. If you want by default to allow a feature, you could have a custom permission called DisableXYZFeature that can be applied via profile or permission set. If each of your custom settings are of this nature, it would also eliminate your need to build a configuration screen, as it would be controlled through the platform's Permission Set and Profile setup screens.
One option missing here is Custom Permissions
For your example, Custom Permissions might be a good fit because it is a boolean enable/disable option. If you want by default to allow a feature, you could have a custom permission called DisableXYZFeature that can be applied via profile or permission set. If each of your custom settings are of this nature, it would also eliminate your need to build a configuration screen, as it would be controlled through the platform's Permission Set and Profile setup screens.
answered Jan 10 at 16:33
jakranz33jakranz33
462
462
That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
– Eduard
Jan 10 at 17:15
add a comment |
That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
– Eduard
Jan 10 at 17:15
That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
– Eduard
Jan 10 at 17:15
That's an interesting solution. Thank you. Yet it's not ideal for my use case. We have 2 Permission sets and controlling feature availability via permission sets or profiles might end up in a situation when users with Permission Set 1 have access to a certain feature, and users with Permission Set 2 don't. Our intent is if the feature is turned on then it should be available across the application.
– Eduard
Jan 10 at 17:15
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f246165%2fwhat-is-the-best-practice-to-store-custom-configuration-for-a-managed-package-ap%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown