We have an AppExchange App which needs to connect with an external application via API Calls. API calls need to happen in individual user context and not in a single Integration User context.

This means to use the External API, every user has to authenticate once to the external application and their Access Token/Refresh Token will be stored in the protected custom settings.

Salesforce custom settings has a storage limit as mentioned in below URL:


For example, if your org has three full licenses, you have 3 MB of custom setting storage. If your org has 20 full licenses, you have 10 MB of storage.

Each certified managed package gets a separate limit in addition to your org limit. For example, let’s say your org has two certified managed packages installed and your organization has three full licenses. Each certified managed package can have 3 MB of custom setting storage in addition to your org’s 3-MB custom setting storage limit.

With the above limitation, using a Protected Custom Setting for an org with a large number of users will be an issue. Based on the calculation shown in the below link, a custom setting's record size is 610 with 2 Text (255) fields. Which will hit the 3MB limit if the number of users exceeds 5156. https://help.salesforce.com/articleView?id=000318587&type=1&mode=1

Question: Is there any alternate to Custom Protected Settings while storing the sensitive information in the AppExchange product for a large number of users? Also, the storage limit for an Org is the hard limit or it can be increased with some add-on after contacting Salesforce?

  • 1
    If you're not able to use named credentials this is quite a knotty problem. Protected custom metadata type records sprang to mind, despite the awkward way you would have to manage these, but these are just as limited with only 10 million "characters" of storage available to your managed package (actually, in total reading how things are counted).
    – Phil W
    Commented Jan 22, 2021 at 9:00
  • 1
    It’s usually possible to contact Salesforce to purchase additional additional data storage. You could try that. Or perhaps someone else on SFSE knows of a (secure) alternative that works nicely with managed packages. Commented Jan 22, 2021 at 9:00
  • 1
    I guess you could hold the data in a regular custom object as long as the stored value is explicitly encrypted and decrypted by the Apex code that manages/uses it. The encryption key could be a single value you store in a protected custom metadata type instance.
    – Phil W
    Commented Jan 22, 2021 at 10:58

1 Answer 1


I think I would address this in two parts:

  • Have a protected Custom Metadata Type record that is set up by the installer for the managed package to contain an encryption/decryption key (and whatever else you want)
  • Have a Custom Object that holds the token in an encrypted form.

This has the benefit that the encryption/decryption is org-specific using some randomly allocated value (set on first installation of the package) whilst allowing the tokens to be held in regular custom objects and thus within the data allocation limits instead of settings or custom metadata limits.

It does, of course, require Apex to manage the data, encrypting when storing, decrypting when retrieving, but you've probably already got that in the mix anyway.

  • Thanks a lot @Phil W, for providing various options to store the large configuration data in a secure way.
    – Ashish
    Commented Jan 22, 2021 at 11:30

You must log in to answer this question.

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