Components are fundamental building blocks that consist of individual items, configurations, and customizations that collectively serve as the fundamental units of a solution - both Zoho CRM Extensions and Vertical Solutions. These components, such as fields, modules, blueprints, widgets, and templates, work together to create a complete and functional solution.
Component properties define various characteristics and behaviours of each component. A component's properties encompass a range of attributes that define the behaviour, appearance, and functionality of the component. Examples of Component properties include a Field's Label, Tool-tip, Worflow's name, description, actions, etc.,
Packaged Components
Packaged Components refers to the components that are developed, published, and distributed to end users by the developer. The end-users here refers to both the Zoho CRM Extension users and Vertical Solutions' subscribers. These components are deployed either during sign-up/installation or as part of an upgrade.
For example, consider a custom module designed for managing client contracts, created in the developer console and published. When the end-users access 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 complete solutions or extensions. This process ensures that each component in the end user'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 end user 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 end user'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 end-user org(s) during sign-ups/installations or version upgrades.
b. Non-upgradable:
Changes are included in the upgraded version of the solution and are only applied to new sign-ups/installations. Existing users 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 end-users.
a. Non-Editable:
Non-Editable properties are locked once published and deployed to end-user accounts, preventing any changes by both the developer and the end-user. 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 end-users cannot make changes. This ensures that the developer maintains control over the component's properties.
c. Developer and User Editable:
Both the developer and the end-user 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 user accounts. This will liberalize the ownership of the component, allowing both the developer and the user 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.