When it comes to scaling a business, Salesforce Admins play a crucial role in ensuring that the growth can be supported seamlessly by the company’s technical infrastructure. To do so, they may look to install managed packages that can support the company’s strategic development while reducing maintenance burdens.
However, these installations come with their own set of challenges. How can you determine the ways in which a managed package could negatively impact the health and agility of your Salesforce environment before you install it? From exceeding Salesforce limits to poor error handling, we’ll provide recommendations to help users mitigate potential issues before they rise.
Avoiding a Salesforce Slowdown
Sometimes AppExchange packages promise the moon but leave your Salesforce organization feeling sluggish and locked-in – therefore, there are many things to consider when looking at new packages.
Perhaps the most familiar and critical concern is the fact that package providers may not fully understand and adhere to Salesforce limits and best practices. This lack of attention to platform nuances can significantly impact the performance of your Salesforce instance. For example, poorly optimized queries or inefficient code execution may result in slow response times, leading to frustration among users.
One package’s code may trigger other packages and create heavy transactions and collisions, which, if not handled correctly, might result in errors. The overall responsiveness of your Salesforce application may be compromised, impeding productivity and diminishing the user experience.
Managed packages often come bundled with a variety of components, including custom objects and fields. While these components may be essential for some users, they can contribute to hitting org limits unnecessarily, creating challenges for organizations with complex customization needs. And while they don’t count towards the edition limit, they do have a limit of their own.
For enterprise editions there are 900 fields, and 400 of those can come from managed packages. Many packages come with undefined empty fields to be mapped at a later stage – these still count towards this limit. Plus, some managed packages come with their own data structures and records. These records may consume additional data storage in your Salesforce org. If the managed package saves the user’s configuration as data, it can also lead to high storage usage.
Another concern exists around how a managed package deals with error handling. The health of your Salesforce instance could be at risk if the package fails to catch errors correctly. Without the proper notifications, users may see an interruption to their other custom code. Others may impact the quality of logging within a company’s Salesforce environment which can delay the user from uncovering issues within the org. This can hamper your team’s ability to quickly identify and address issues, impacting the overall health of the Salesforce instance.
How to Evaluate a New Salesforce Managed Package
Despite potential pitfalls, managed packages are still an important backbone in the Salesforce ecosystem and when done well, they can optimize the way you work with Salesforce. Here is a checklist of factors to consider before committing to a new managed package:
Deployment
- Are sandbox testing requirements clear?
- What editions/licenses are supported?
- Are there automatic updates for new versions?
- What is the deployment process between sandbox and production?
- Are there dependencies on non-packaged metadata?
Footprint Evaluation
- What is the managed package’s impact on data storage?
- How does it handle large volumes of data?
- Does it use Salesforce’s best practices for saving user configurations?
- Were transaction times taken into account when developing?
- How does it handle collisions with other managed packages?
Data Security
- How are data access and sharing permissions handled?
- Are new user profiles or sharing rules required?
- Is sensitive data encrypted and anonymized?
- Does it comply with relevant data privacy regulations?
- Are there audit logs for data access and changes?
Testing
- Are there regression testing tools or documentation?
- Is sandbox testing safe and effective?
- Are there clear and informative release notes?
Vendor Vetting
- Does the vendor have a good reputation?
- How responsive is the vendor’s support team?
- How committed is the vendor to security and compliance standards?
- Are there references from other clients using the same managed package?
A Salesforce Managed Package Solution
As you navigate the challenges of managed packages, it’s worth exploring solutions that actively embrace best practices from the outset while simultaneously optimizing the way in which your team – and your company – is using Salesforce.
Take Sweep, for example. Built with admins in mind, Sweep is a visual workspace for Salesforce that enables companies to optimize their business processes without sacrificing architecture integrity.
In developing Sweep’s managed package, CTO Eran Kirshenboim remained focused on the fundamentals.
Additionally, Kirshenboim emphasizes the importance of data and metadata security, and how Sweep goes beyond SOC2 compliance to assure security.
For a considered managed package that adheres to Salesforce best practices, check out Sweep.
Summary
By navigating the challenges of Salesforce managed packages with foresight and strategy, organizations can harness their benefits while maintaining the integrity and efficiency of their Salesforce environment. Remember: it’s always easier to prevent these problems than solve them later – so keep this managed package evaluation checklist handy.