I have a platform cache partition that is packaged as part of a managed package. Once it is installed in a subscribers org it defaults to zero capacity.

Using getPartition() and OrgCacheException I can detect if it is present or not - as per Clean way for code to work with or without Platform Cache?.

private static Cache.OrgPartition FooOrgPartition {
    get {
        Cache.OrgPartition orgPart = null;
        string cachePartitionName = 'PackageNamespace.FooPartitionName';
        try {
            orgPart = Cache.Org.getPartition(cachePartitionName);
        } catch (cache.Org.OrgCacheException ex) {
            System.debug(LoggingLevel.Error, 'FooOrgPartition - failed to getPartition with name ' + cachePartitionName);
        return orgPart;

However, once I have the partition how can I tell if it has any capacity at all?

Default managed package allocation

Looking at the Partition methods the obvious candidate appears to be getCapacity().

Returns the percentage of cache used of the total capacity for this partition.

However, that method comes with a catch. From Platform Cache Best Practices:

Minimize Expensive Operations
* Use Cache.Org.getKeys() and Cache.Org.getCapacity() sparingly. Both methods are expensive, because they traverse all partition-related information looking for or making calculations for a given partition.

I don't want to waste time checking or attempting to populate a cache partition with no capacity at all. Nor do I want to slow down the actual usage of the cache when it is needed by calling getCapacity(). The whole point of the cache was to speed that scenario up.

Am I missing an inexpensive way to detect cache partitions with no capacity?

Some additional thoughts:

  • It doesn't appear to be possible to delete the packaged cache partition from the subscribers org. As a packaged component there is no indication that it can be deleted from the subscribers org without uninstalling the package.
  • I could use a custom hierarchy setting or feature parameter to toggle the functionality, but I'd prefer to directly detect the cache status based on its actual configuration.
  • 1
    What's more expensive - getCapacity or a cache miss? The answer to this question would dictate your approach. A partition without capacity makes no sense..
    – identigral
    Commented Mar 24, 2020 at 20:51
  • @identigral I'm not sure it is that simple as that. If the cache is empty or has no capacity then the cost to call getCapacity is negligible. However, if the cache is larger and is under heavy use then the cost becomes significant, hence the reference to not calling it in the linked best practices. The whole point of using the cache is to improve performance when it is needed. I just have no safe mechanism to detect if it should be used or not. Commented Mar 24, 2020 at 22:07
  • Did you get anywhere with this @daniel? I'm currently looking to utilise Platform Cache in a managed package...
    – edralph
    Commented Dec 10, 2020 at 21:33
  • I'm still stuck in the same position. I've raised the same question in the Trailblazer Community dedicated to Platform Cache. Hopefully we can get some insight from a Salesforce employee. Commented Dec 10, 2020 at 22:56

2 Answers 2


I've discovered that in the Spring 21 release, Salesforce is including automatic provisioning of 3Mb Platform Cache partition for your app in all EE and up subscriber orgs that your package is installed into. It will be free of charge.

Here's a snippet from their Spring 21 Release Notes (hefty document):

Free Platform Cache for Managed Packages (Generally Available)

Salesforce provides 3 MB of free Platform Cache capacity for AppExchange-certified and security-reviewed managed packages. This feature is made available through a capacity type called Provider Free capacity and is automatically enabled in Developer Edition orgs. Where: 3 MB of free Platform Cache is available in Developer Edition. How: Allocate the Provider Free capacity to a Platform Cache partition and add it to your managed package. When the AppExchange-certified, security-reviewed managed package is installed on the subscriber org, the Provider Free capacity is allocated and automatically made available to the installed platform cache partition. The managed package can then start using the Platform Cache partition. Provider Free capacity is available with first-generation and second-generation packaging. For second-generation packaging, to create a scratch org with Provider Free capacity, see the ProviderFreePlatformCache feature. Note: If the managed package isn’t AppExchange-certified and security-reviewed, the Provider Free capacity resets to zero on package installation.

Whilst it doesn't directly answer your question, it hopefully resolves the challenge you have.


As at today (Spring '21) it isn't currently possible to tell if a Platform Cache partition has any capacity allocated.

In a conversation with Mike Faust it came up that getCapacity() wouldn't actually be much help:

Returns the percentage of cache used of the total capacity for this partition. Docs

It's going to return 0.0 when the cache has no capacity and when it hasn't been populated yet. So even if it wasn't expensive it isn't going to give any indication of capacity being available from a starting state.

As edralph answered, in Spring `21 we could use the free 3MB of Platform Cache to ensure there is at least some capacity available in AppExchange approved (security-reviewed) apps.

However, I think there are edge cases that this doesn't help with. E.g. non-managed packages in developer edition orgs. Or managed packages with specialized caches that aren't applicable to every subscriber. If there was a cache partition that was only useful to a subset of orgs with the package installed you wouldn't want to use some of the 3MB free allocation on it.

It seems like it would be a lot easier if we could just call a method and determine the capacity allocated to the cache partition. I've raised an idea as such Apex method to expose the total capacity allocated to a Platform Cache partition

You must log in to answer this question.

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