Components are fundamental building blocks of Vertical Studio applications, comprising functionalities, configurations, and customizations. These components, such as fields, modules, blueprints, widgets, and templates, work together to create a complete and functional application.
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 an application. 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 understand how packaged components are managed in the developer console and in subscriber orgs, we use two control terms: Upgrade Type and Subscriber Modify Access. Upgrade Type defines deployment behavior during sign-up and version upgrade. Subscriber Modify Access defines whether subscribers can edit a property in their org.
1. Upgrade Type
Upgrade Type defines whether changes made by the developer to packaged component properties are applied to subscriber orgs during an application upgrade. Upgrade type can be of two types:
a. Upgradable:
Changes to the packaged components are automatically included in the next version of the application. These updates are deployed to the subscriber org(s) during sign-ups or version upgrades.
Upgradable properties are developer editable in the developer console.
b. Non-upgradable:
Changes are included in the upgraded version of the application but they are only applied to new sign-ups. Existing subscribers do not receive these updates during an upgrade.
2. Subscriber Modify Access
Subscriber Modify Access defines whether subscribers can edit a packaged component property in their own organization.
a. Yes
Subscribers can modify the property in their subscriber org. These changes will not be affected by any further upgrades.
b. No
Subscribers cannot modify the property in their subscriber org.
c. Non-Editable exception
For specific locked properties, neither the developer nor the subscriber can edit the property after save or publish. For example,
in Workflow configurations, the module property is locked and cannot be changed by either side.
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.