Things which should be considerable to know before spending thousands of $$ on another Salesforce managed package

Salesforce Managed Packages: Promising Solutions in Theory, Complex Challenges in Implementation.

The concept of reusing existing code instead of writing the same feature again is not new. It has been used multiple times and is the foundation of all SaaS businesses. However, what I have observed over time while working in different Salesforce environments is that each one is unique.

Packages that work perfectly fine in small Salesforce environments might cause issues in larger ones. One of the challenges I face as an architect is the lack of code visibility. I often have limited knowledge of what is happening inside the system, such as which objects are being triggered and how.

Before you buy, it would be wise to challenge the creator with the following questions:

• Which database objects are modified/created/deleted in synchronous transactions?

• In case of issues, what are your SLAs for resolving them?

• Can I connect with your current client to hear their opinions on the system? (It would be wise to connect with someone who works for this client as a developer or architect. They can provide realistic opinions. Sometimes a search on LinkedIn is enough to get some realistic feedback before spending a significant amount.)

• Can you test the package in your full-copy sandbox before installing it in production?

• What is the rollback plan in case of issues? (Is it possible to uninstall the package without harming the data?)

If you would like me to perform this checkup, please book a consultation. Investing $400-600 in my services could potentially save you $20,000 (or a much higher sum) on a wrong package.