We are developing AppExchange product where we need to communicate with different third party systems.For Instance , we are getting services from 5 different third party system,a user can have 5 credentials accordingly. In such cases , where can we store the credentials and related fields of the users.

  • Do you have any updated information in the context of this StackExchange thread? What was the approach you used for your product? How salesforce reacted to the usage of named creds in AppExchange product? Commented Feb 4, 2021 at 7:28

1 Answer 1


It depends on a few things.

If the external systems are going to authenticate with OAuth, then Named Credentials are great. They are secure (even your own code can't get the secret values directly), and handle OAuth out-of-the-box.

However, Named Credentials are not well documented for the OAuth use-case (and not very configurable if anything unusual is required). So, if it doesn't just work, you may run into something that makes that method impossible to use.

In principal, Named Credentials can be used to log into external system with a simple username/password authentication. The hard part is that you can't easily provide your own UI to allow users to set up their details. See Is it possible to set per user Named Credentials via Apex? or a good but complicated way and Possible to update NamedCredential from Apex? for a quick + dirty way.

The tried and tested method is to use protected custom settings. When you define a custom setting in your package as protected, the subscriber org cannot read it except via your code. So, you can provide an UI in Lightning and/or VF so that they can enter their details. The user's private detail are protected from everyone else in the subscriber org, but bugs in your code could allow them to leak out. This is the method that has been used for years and is acceptable to Salesforce's security review team for listing on AppExchange.

  • 1
    We have a package in which we accept a username/password in Visualforce, make a direct callout from the front-end to Metadata API to create the Named Credential (similar to how DLRS' Create Remote Site Setting button works), and then wash our hands of the password and never have to deal with it directly again. Not sure what Security Review will think of this when we get there, but it works well for now.
    – Charles T
    Commented Dec 4, 2018 at 13:21
  • @CharlesT Do you have any updated information in the context of this StackExchange thread? Commented Feb 4, 2021 at 7:26
  • We passed Security Review, still using this approach to helping the user create Named Credentials.
    – Charles T
    Commented Feb 4, 2021 at 13:31

You must log in to answer this question.

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