Salesforce Installed Packages: A Guide to Implement Salesforce Packages

Salesforce provides several methods to extend its capabilities, primarily through two fundamental approaches for deploying pre-built solutions onto your Salesforce org: Managed Packages and Unmanaged Packages. Businesses can use these packages to quickly implement new features and functionalities through efficient deployment. The successful implementation of Salesforce packages requires firms to understand their differences and implications and follow the best practices for maintaining a secure environment.

What are Salesforce Packages?

A Salesforce package serves as a container that holds various Salesforce components, which include but are not limited to custom objects and fields, as well as Apex classes, Visualforce pages, flows, and reports. Developers can use packages to group their components for distribution to other Salesforce organizations.

Managed Packages

Salesforce partners (ISVs) develop Managed Packages that they intend to distribute and sell, which can be of two types: Verified Managed Packages and Unverified Managed Packages. Salesforce allows its partners to sell their Managed Packages through the Salesforce AppExchange only if the package undergoes a security review by the Salesforce team. The “Managed” designation of these packages means that installing organizations cannot modify specific components.

Closed to Modifications: The majority of managed package components remain protected from modifications. The package allows modifications to particular components but prevents users from altering its Apex code, LWC Components, Visualforce Pages, and Custom Objects directly. This protection keeps the solution safe from being altered by the end customers.
Salesforce Verification: Salesforce enables ISV partners to submit their Managed Packages for verification, allowing them to list these packages on AppExchange. During the review, Salesforce performs a comprehensive verification of managed packages to confirm they adhere to both Salesforce coding standards and security requirements. This verification is a strong indication that the package is of high quality and will function properly. Managed packages that haven’t been verified are Unverified Managed Packages that haven’t undergone this review and will therefore not be listed on AppExchange.
Governor Limits: Verified managed packages operate under their own set of governor limits, which represent a significant advantage. The Apex code and operations executed within verified managed packages use their own separate governor limits, which do not affect your organization’s total governor limits and do not negatively affect the performance or scalability of your custom code or other installed applications. The query limit of 150 SOQL queries per transaction in your organization does not apply to a verified managed package, as it operates under its own separate limit. This allows the package to execute its operations without reaching your org’s query limit.
Upgrades: The package developer can either release the packages in the form of a subversion or the main version. A subversioned package enables the Salesforce ISV provider to bypass Salesforce verification and release bug fixes or new features quickly to consumers. In contrast, upgraded Managed Packages released in the form of a main version must undergo a complete Salesforce review before being listed on AppExchange. Organizations can either opt for automatic package upgrades (which will be done by the ISV provider) or allow the System Administrators to upgrade manually by vetting in lower environments before moving to the Production Instance. In either approach, Managed Packages do not need to be uninstalled and reinstalled.
Intellectual Property Protection: ISVs can protect their intellectual property through managed packages because subscribers cannot access or modify the underlying code and schema.

Unmanaged Packages

Unmanaged packages are best suited for deployment situations that require one-time use or component sharing between development environments or other organizations that require full editability. The installation of unmanaged packages results in complete editing capabilities for all components within the destination organization.

Open to Updates: After installing an unmanaged package, all its components become completely accessible and editable within your Salesforce organization. The flexibility of this approach requires you to maintain and update these components.
No Salesforce Verification: The Salesforce verification process does not apply to unmanaged packages. The installing organization must perform comprehensive security checks on package code and components, as Salesforce does not verify unmanaged packages.
Governor Limits: The governor limits of an organization apply to all operations and code introduced by unmanaged packages since they do not have their own separate limits. Unmanaged package code operations will utilize the governor limits applicable to the organization where the package is installed. The governance limits of your entire organization are at risk when unmanaged package code contains poor optimization, as it will trigger exceptions.
No Seamless Upgrades: Unmanaged packages require different upgrade procedures than managed packages because they cannot receive standard package upgrades. The installation of new unmanaged package versions requires either installation in a developer environment and deployment to Production using deployment tools or complete removal of the previous version, followed by the installation of the new version, which may cause system disruptions.
Sharing and Customization: Unmanaged packages are best suited for sharing templates, sample applications, or moving components between different sandboxes or between a developer organization and a client’s organization for further customization.

Salesforce Package Comparison

Governor Limits in Detail

Understanding how governor limits apply to different package types is crucial for achieving optimal performance and stability.

Verified Managed Packages and Governor Limits

When a verified managed package is installed, its Apex code runs in a separate execution context with its own set of governor limits. This is a critical distinction for complex applications.

Example: The transactional DML statement of 150 in your org remains available to your custom code when a verified managed package executes 150 DML statements during the same transaction.
Benefits: The isolation mechanism prevents a single, resource-intensive managed package from controlling all organizational resources, thereby extending the time before custom code reaches its limits. The system enables ISVs to develop robust applications that do not negatively affect the subscriber’s organizational resources.
Note: The specific documentation should be reviewed to determine how CPU time and other limits interact with each other. The documentation for each managed package should be consulted to determine its resource usage.

Governor Limits for Unverified Managed Packages and Unmanaged Packages

Unverified managed packages, along with all unmanaged packages, do not have an isolation.

Example: The remaining DML Statements available to your custom code within a transaction will be approximately 50 after an unmanaged package executes 100 DML Statements when your org has a transaction limit of 150 DML Statements.
Impact: The code inside unverified Managed Packages or Unmanaged Packages directly battles with your organization’s custom code and other applications for the same governor limits. The lack of proper management will result in performance problems, transaction failures, and overall system instability.
Responsibility: The installing organization must take full responsibility for maintaining efficient unmanaged package code that stays within governor limits.

Static Resources and Governor Limits

All static resources from any type of package, including verified managed, unverified managed, and unmanaged packages, will use the storage limits of the installed organization. The storage limits of an organization are affected by static resources, including images, stylesheets, and JavaScript files. However, these resources do not face the same execution-time governor limits as Apex code.

Things to Do Before and During Implementation of Any Package

The installation of packages without a comprehensive evaluation introduces numerous risks that can impact system performance and pose security threats. The following checklist provides a complete method to follow:

1. Always Install in Lower Sandboxes First

The installation of packages should never happen directly in production environments. The package installation process must start in a lower sandbox environment (such as Developer sandbox, Partial Copy sandbox, Full sandbox) before moving to production deployment. The process enables you to:

Evaluate how the package affects your current customizations in the Salesforce Org.
Display all the potential conflicts and unexpected operational issues within the Salesforce Org.
Test with your organization’s data and operational processes to ensure accuracy.
Evaluate the resource usage in the Salesforce Org.

2. Check Installed Components and Object Access

Examine all components from the package with great attention to detail post installation. The installation wizards will also display a list of components from the package.

Component List: Your organization may receive custom objects and fields, Apex classes and triggers, Visualforce pages, flows, and reports as part of the package.
Standard Object Impact: Depending on the functionality developed, the package can interact with standard objects (Account, Contact, Opportunity) or require custom components to be developed. The evaluation of data model changes and conflicts requires this information.

3. Ensure Package Functionality Will Not Override Custom Apex

The package functionality requires verification of Apex classes and triggers to prevent accidental override or conflict with your existing custom Apex classes, triggers, and workflows.

Code Review (for Unmanaged): The evaluation process for unmanaged packages requires a complete code review by an experienced Salesforce developer to detect potential conflicts and inefficient code.
Documentation Review (for Managed): The documentation review of managed packages should focus on known conflicts and best practices for integrating with existing customizations.

4. Understand User Provisioning and Licensing

The process through which users access the package features is a critical factor.

Permission Sets: Managed Packages serve their own access control mechanism. The permission sets determine which objects, fields, Apex classes, and Visualforce pages users require to use the package.
Managed Package Licenses: User access to managed packages is determined by the licenses, which control their usage. Users who need access to the package must receive an assigned license. The Managed Package License is only applicable to Managed Packages.
Combination: The implementation of permission sets together with managed package licenses provides a method to control user access appropriately.

5. Create a Permission Set Group (Recommended Practice)

A highly recommended best practice for permission set assignment is to avoid direct package-specific permission set assignment to users:

Create a new Permission Set Group: Name it logically (e.g., “Package Name – Users”).
Add Package Permission Sets: Add relevant permission sets created from the package to this newly created permission set group.
Benefits: This approach centralizes permission management, makes it easier to assign and revoke access, and simplifies audits.

6. Mute Package Permissions as Needed

The default permission sets of packages provide excessive access to specific fields and objects, which require restriction for particular users, so that you can modify these permissions:

Muting Permission Sets: Within the permission set group you created for the package, you can create a “Muting Permission Set.”
Restrict Access: Use the muting permission set to explicitly revoke or restrict access to specific fields or objects that were otherwise enabled by the package’s default permission sets within that group. This provides granular control without modifying the package’s original permission sets.

7. Secure External Application Integration

If the package integrates with an external application, meticulous security measures are paramount:

Dedicated API User: Create a separate integration user in Salesforce with “API Only” access enabled. This user should not have a standard login or UI access.
Minimal Permissions: Grant this API-only user only the absolute minimum required permissions (objects, fields, Apex classes) necessary for the external application to function.
Restrict Metadata Access: Do not grant Modify All, Modify Metadata Access to the Integration User unless explicitly requested. This is to prevent risks associated with accidental modifications made to metadata and data within the system.

8. Control UI Component Visibility with Custom Permissions

To ensure that package UI components (e.g., custom tabs, Visualforce pages, Lightning components) are only displayed to users who actually have access to them:

Develop a Custom Permission: Establish a custom permission inside your Salesforce organization, which should be named “[Package Name] UI”.
Assign to Permission Set: Grant this custom permission on one of the package-related permission sets within your permission set group.
Component Visibility: Use this custom permission in your Lightning app builder to conditionally display package components based on whether the user has this custom permission. The approach delivers an organized user interface while blocking users from accessing unavailable features.

9. Verify Audits post the installation and configuration

The tracking of audit logs remains essential for all package types, both during initial implementation and subsequent upgrades, particularly in lower environments, to determine which components receive modifications or replacements. The audit logs help you track two essential elements:

What is being overridden: The system tracks all modified components through its audit logs.
What components are decommissioned: The system tracks which components no longer exist within the package framework.

Planning for Deprecated or Upgraded Components

Testing results and audit log analysis from lower environments will help you create a deployment strategy:

Develop an Upgrade Plan: The upgrade plan should include actions for components that were deprecated, upgraded, or added in the new package version.
Data Updates: Plan to take proper backups before upgrading the package in the Production Environment. Migrate the data to another custom field if the data will be reused for any other purposes in the future.
Utilize Deployment Tools: For Unmanaged Package, use standard or custom Salesforce deployment tools to carefully transfer the updated or new components from your lower sandboxes to your production environment. This guarantees a controlled and well-documented process deployment.

Conclusion

The Salesforce platform expands its capabilities with both managed and unmanaged packages. The key differences between these package types require organizations to develop strategic plans because they impact updateability, Salesforce verification, and governor limit usage. Organizations can maximize the benefits of pre-built solutions by following best practices, such as sandbox testing, user provisioning, and implementing security measures, to maintain the stability and performance of the Salesforce platform. Understanding these details enables administrators and developers to make informed decisions that enhance business operations and user experience.

Salesforce Installed Packages: A Guide to Implement Salesforce Packages