Components are fundamental building blocks that consist of individual items, configurations, and customizations that collectively serve as the fundamental units of a solution. These components, such as fields, modules, blueprints, widgets, and templates, work together to create a complete and functional solution.
For example, consider a custom module designed for managing client contracts, created in the developer console and published. When the subscriber accesses it, the module's behavior, including customization options and permissions for editing or removal, adheres to the established packaging guidelines.
Packaging allows developers to distribute these components collectively by publishing them as a solution. This process ensures that each component in the subscriber's account adheres to the predefined rules for editing and removal. Detailed guidelines on managing these components are outlined in the next section.
Managing Packaged Components
To gain a deeper understanding of how the packaged components can be managed at the developer console and at the subscriber accounts, it is important to understand the key concepts of upgrade types and modify access. These terms clarify how components behave during upgrades and who can modify them post-deployment.
1. Upgrade Type
Upgrade Type defines whether the changes made by the developer to the packaged components will be deployed during an upgrade in the subscriber's accounts or not. Upgrade type can be of two types:
a. Upgradable:
Changes to the packaged components are automatically included in the next version of the solution. These updates are deployed to the subscriber org(s) during sign-ups or version upgrades.
b. Non-upgradable:
Changes are included in the upgraded version of the solution and are only applied to new sign-ups. Existing subscribers do not receive these updates during an upgrade.
2. Modify Access
Modify Access defines who can modify the specific properties of packaged components or delete them after they have been published and made available to the subscribers.
a. Non-Editable:
Non-Editable properties are locked once saved or published and deployed to subscriber accounts, preventing any changes by both the developer and the subscriber. This restriction is applied specifically to the properties of the component, not the component itself. For instance, the 'Formula Return Type' in a formula field is a non-editable property, meaning it cannot be modified after it has been set and deployed.
b. Developer Only:
Only the developer can modify the properties of the packaged components, while subscribers cannot make changes. This ensures that the developer maintains control over the component's properties.
c. Developer and Subscriber Editable:
Both the developer and the subscriber can edit the component properties. However, changes made by the developer will only be included in new versions for new sign-ups and not retroactively applied to existing subscriber accounts. This will liberalize the ownership of the component, allowing both the developer and the subscriber to modify it as per their respective needs.
Altogether, every packaged component by itself, and its respective properties, will have a defined upgrade type and modify access.
Destructive Changes
Any modifications, deletions, or updates pushed as upgrades to the subscriber accounts that may have permanent and irreversible effects on your subscriber data or configurations are classified as Destructive Changes.
Please be aware of the potential consequences of any destructive changes performed by a developer before proceeding:
- Data and Configuration Loss: Deleted or modified subscriber data or configurations cannot be recovered once the upgrade is deployed.
- Operational Disruption: Changes may impact critical processes in the subscriber's organization, including workflows, customer interactions, billing, and reporting.
- Compliance Risks: Altering or deleting certain data or configurations could lead to non-compliance with regulatory or contractual data retention requirements.
We recommend the following precautions when performing such actions:
- Thoroughly review all changes with utmost care to prevent unintended data or configuration loss.
- Test changes before deploying to the subscriber's production environment.
- Communicate the changes to the subscribers well in advance so that they will be prepared for any potential impacts.