function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Managed Package Disadvantages/Impact Analysis



I have installed a Retail Insurance application named : Wealth Management in our org. It uses a managed package named "Relationship Groups" used for Householding Contacts together.


Now, customer is of the opinion that the app is not catering to the needs of the business requirements. However, we as consultants are of opinion that the app is very useful and will map the business needs. For basing our facts, we are documenting and analysing the app for its Pros, Cons, Impact on current system, Usage, etc.


One of the factors we want to know more about is how much impact does Managed Package have on the system where it is installed? I mean like I know we cannot change the underlying codes of Apex triggers/visualforce pages, etc. But let say customer comes up with requirements tomorrow wanting to change the behavior of the system which comes up due to behind-the-scene programs written. I know we cannot change it, but can we have workarounds to mitigate those behaviors? Is it possible for Managed Package components?


I want to know how Managed Package influences the system and what impact can it have on the system going forward in future.


Can anyone please assist me with this?







The question you're asking really depends more on the underlying code and it's quality, than the fact that it's managed. Managed packages can be architected in such a way as to allow extensibility, either to point and click admins. through custom settings that can be configured or to developers by making the underlying codebase extensible from outside the package (global virtual).  


If the managed package was architected without extensibility in mind, then you pretty much get what you get in terms of extensibility, unless the ISV is particularly responsive and willing to make changes to their package to accommodate you.  There are a few ISV partners who are willing to bend and adapt for specific clients.  But otherwise, you get what you get and the client can't demand changes to how the code functions.  


As a client, and this is the primary benefit of managed packages, you have a clear upgrade path (bug fixes, etc.).  Many ISV's also value that managed packages are closed source code, so they get IP protection.  


You should feel pretty comfortable with the package and the ISV, because if they go out of business, your managed package can languish and you have no way of making fixes.  You pretty much have to extract your data and start from scratch if something is broken.  


Hope this info helps.