This article mainly focuses on an important aspect of the certified managed package, the Limit property. What this property means and why it is important.
What are Packages?
Packages in Salesforce are tools for distributing components between environments. The package can contain a very wide variety of components, such as objects, fields, automation processes, code, and more. Packages do not contain data.
Packages can be divided into two types: Managed and Unmanaged. While Unmanaged is like open source, where the components can be modified after installation, Managed is the opposite, and most of the components are locked and managed by the package provider.
The Managed packages can also be divided into two subtypes: certified and uncertified. A certified package is a package that has passed the Salesforce security review process to verify that it meets specific standards and security levels, which allows the provider to publish it on the AppExchange.
There are a few differences between certified and uncertified, and a very important one is the Limit property. The property means that the package has its own limits. But, what does it really mean when it says "has its own limit"?
Limits?
Anyone working on the Salesforce platform knows that there are plenty of limits. Some are organizational limits, such as the number of fields per object or number of tabs, others are limits per transaction, such as total SOQL queries.
Certified package components and execution don't count toward the organization's limit, they are being counted separately. Well, at least for most of the limits, and yes, there are also cumulative limits. That is the total limit for all the certified packages that run together in a single transaction.
Trying to Simplify
Components from certified managed packages are not counted in the organization's limits. There are few exceptions, but in general it is simple. If, for example, your organization has a limit of 400 custom objects and a certified package adds 10 custom objects, those 10 won't be counted under your 400 custom objects.
As for the transaction limits, things are getting a little bit complicated. There are some transaction limits that each certified package gets a separate counter for. In most of them, the certified package gets similar limit as the organization (but separated), while the cumulative limit in the transaction (organization plus all certified packages) cannot exceed the Transaction Limit*11.
Here are a few transaction limits that can clarify the count logic:
For some limits, the certified package doesn't get separate limits. The most important limits in this category are: the Heap Size (6MB limit) and the CPU Time (10,000 milliseconds limits).
Importance of the Limit Property
For many packages and implementations, it might not be critical. If the organization doesn't close to any organizational limit and the package processing works on its own data, then it won't make too much difference.
On the other hand, it is very important when the organization has intersectional processes with the package processes. For example, if when a new Account is created, there is a custom trigger on the organization and also trigger from a managed package. In such a case, the additional processing from an uncertified package can cause a limit exception. Moreover, as each organization has a different implementation for the Account, it is very likely that for most organizations, the package trigger will work but will fail for a few others with lots of complex customizations.
The Certified Package, due to the Limit property, doesn't suffer from this issue. It can still hit the limit due to its own processing (or due to the unseparated limits), but still the separate Limit counters reduce significantly the chances for hitting the limit.
No comments:
Post a Comment