Apex Code Development You need to sign in to do that
Don't have an account?
sai kumar 625 managed package Issues
Hello Community Members,
I have created a managed package along with the custom profiles available in my org and installed package in other developer org, but I dont see any custom profiles installed in the target org . Please help me with this and also help me with any sort of documentation that explains about the limitations of managed package that I can use it for reference. Your help will be really appreciated, thanks in advance.
I have created a managed package along with the custom profiles available in my org and installed package in other developer org, but I dont see any custom profiles installed in the target org . Please help me with this and also help me with any sort of documentation that explains about the limitations of managed package that I can use it for reference. Your help will be really appreciated, thanks in advance.
Sorry for this issue you are facing.
When you install a package, you choose which Profiles are granted access as part of the install. Having "shell" profiles won't help. Any Profile you don't select it will need to have an object, field, and component access granted manually.
Installing the package using the choice you selected updates all the appropriate existing Profiles with access to the package components. Profiles for license types that are not eligible for the component access are not updated.
There is no "migration" -- the package just gets installed.
When you install a package, you choose which Profiles in the org you are installing into should be granted access to the components in the package. You can always grant access to additional users by updating other Profiles and/or using Permission Sets.
Please find the limitations below:
Managed Packages – limitations:
When taking a decision to use this mechanism, we should realize that there are some issues that may be of critical importance in the decision-making process.
- Changes in the data model are the key limitation. When the data model is embedded into the package, modification of the field type or its properties becomes severely limited. At the time when a field is added to the package, such attributes as API name, uniqueness or External ID may not be changed. In line with the whitelist principle, Salesforce lists the things that may be done in the “packaged” data model in the documentation. Hence, it implies that no modifications, except the ones mentioned above, are possible.
- Another important aspect of the introduction of packages is blocking any modifications of global class definitions and their methods – thus also the web service. The methods may not be extended to accept additional parameters or deleted. This means that once created, a web service cannot be switched off. The only thing that can be done is the creation of a new method/class and designation of the old one as “deprecated” together with deletion of its code.
- A lack of the possibility to update user profiles is a major administrative limitation. Profiles may be used for purposes of defining a user’s access to specific system functionalities and data (CRUD definition at the object level). In the course of package installation, profiles become connected with those which already exist in the environment. However, no profile setting changes are migrated at the time of package upgrade (newer version installation). All we can do is to make profile changes manually in each environment. Number of environments may be reduced through the use of advanced migration scripts.
- As the package content (mainly the code) is hidden and the package is managed in a separate Salesforce development environment, the package may be developed only in that environment.
- The package always uses the latest version of the whole packaged code. This poses huge problems with code branching – though development of a patched version is partially supported. It is impossible to work on different software version functionalities at the same time, while a release of a new version of the package requires the completion of all package functionalities being developed.
- Additionally, the environment where the package is developed offers only two user licenses. This means that the application will be developed by the maximum of two people or that the user accounts will be shared, which is going to make change tracking difficult.
- The final issue I’d like to discuss is a serious limitation of operation automation.
- At present, a new version of the package may only be created manually from the user interface level, by entering the right environment. This means that release of new versions (also test ones) may not be automated. If you use a Managed Package, you have to forget about Continuous Integration.
Hope this helps.Kindly mark this as solved if the reply was helpful so that it gets removed from the unanswred queue which results in helping other who are facing a similar issue.
Thanks,
Nagendra