Working with Custom Modules
Custom modules are modules you build in Vertical Studio to address business requirements that pre-built modules cannot cover. While Vertical Studio includes 10+ pre-built modules for Sales, Marketing, Customer Support, and Inventory management, custom modules can be tailored to fit your exact business use case and logic.
Use custom modules when you need to store data that is specific to your business process and cannot fit into the existing pre-built module structure. For example, in a real-estate application, you can create custom modules for Properties and Buildings that link with pre-built modules like Leads and Contacts, enabling your subscribers to manage their complete workflow in one place.
Custom modules are fully packagable components. You can add fields, define page layouts, set access controls with roles and profiles, create workflow rules to automate processes, and build relationships by linking custom modules with standard modules or other custom modules. When you publish your application, custom modules are included in that version. However, a custom module is only visible to subscribers if it is added to your application's pricing before publishing. Your plan tier determines the maximum number of custom modules you can create. For details on plan tier limits and how they affect your application, refer to Plan Tiers - Features and Pricing.
How to create and manage custom modules in Developer Console
Create a custom module
- Log into your Developer Console.
- Navigate to Vertical Studio and select your application.
- Click Modules in the left pane.
- Click + New Module.
- Update the module name by clicking the existing one.
- Enter the singular and plural form of the module name and click Save.
- Add custom fields and sections as needed, then click Save Layout.
- Select the profile(s) that will have access to this module, then click Save.
When you create a module, Vertical Studio automatically adds a few fields to the module. You can add more custom fields and customize the page layout after creation.
After creating the module, add it to your application's pricing before publishing.
A custom module is only visible to subscribers if it is included in the pricing.
Edit a custom module
- In the Modules page, select the module you want to edit.
- Select the layout in which you want to make the changes.
- Make the necessary changes and click Save.
Link custom modules with other modules
Create relationships between your custom modules and standard modules (or other custom modules) using Lookup fields. This enables subscribers to connect related data and build cross-module reports.
To create a lookup field:
- Navigate to the custom module you want to link.
- Drag a Lookup field from the New Fields panel.
- In the Lookup Properties dialog, enter:
- Field Label: Name for the lookup field
- Related Module: Select the module you want to link to (e.g., Contacts)
- Related List Title: Title for the related list that will appear in the related module.
A related list will automatically be created in the linked module, allowing subscribers to see related records.
Example: In a real-estate application, you create a Properties custom module and want to link each property to a contact. You add a Lookup field in the Properties module, set the Field Label to Contact, and select Contacts as the Related Module. Each property record now has a contact lookup field, and a Properties related list appears in each Contact record, showing all properties associated with that contact.
Relationship patterns and linking modules
Use lookup-based relationships for one-to-many scenarios and linking modules for many-to-many scenarios where association-level data must also be stored.
- One-to-many relationship: One record in Module A can link to one record in Module B, while Module B can contain many linked records from Module A. Example: Multiple orders linked to one customer.
- Many-to-many relationship: Records in both modules can connect to multiple records in the other module. Example: Students enrolled in multiple courses, and each course has multiple students.
- Linking module: Use a linking module as a junction between two primary modules when you need to store additional data about the association itself, such as enrollment date, completion status, or score.
A linking module acts as a junction between two primary modules in a many-to-many model. Each association can be stored as a separate record so you can capture relationship-specific data.
Example: A Student-Course linking module can store Enrollment Date, Completion Status, and Score for each Student-Course association.
Use this pattern when the relationship itself matters as much as the connected records. Keep the linking module focused on association-level fields and avoid adding data that belongs to either parent module.
Validation checklist:
- Confirm the relationship type matches the business process, such as one-to-many versus many-to-many.
- Review related-list visibility and permissions in subscriber orgs before rollout.
- Check reporting and export constraints if the linked module or association records are part of operational reporting.
- Confirm lifecycle behavior when a parent module is hidden, retired, or removed from an application version.
Organize modules
Control which custom modules appear in your subscriber Organize modules lists and set their default order. Subscribers can also reorder modules by dragging them in their own Organize modules setting.
- In the Modules page, click Organize Modules.
- All modules are selected (shown) by default. Uncheck a module to hide it in the subscriber org.
- Drag modules in the Selected Modules list to set their default order.
- Click Save.
Important: Custom modules only appear in subscriber Organize modules if they are also visible in all three standard UI locations (Modules list, Web UI, Tab Menu) in your Module Visibility settings. If a module is visible only in Reports or Data Import, it will not appear in the subscriber Organize modules list, even if enabled here. To make a module available for subscribers to customize, ensure it is visible in all three standard UI locations. For details, refer to Module Visibility.
The Organize modules configuration (including module order) is non-upgradable and applies only to new subscriber signups. Existing subscribers are not affected by changes you make here. Subscribers can reorder modules in their own Organize modules setting, and that preference persists across upgrades.
Delete a custom module
You can only delete a custom module if it has not been published as part of any application version. Once a custom module is included in a published version, it cannot be deleted.
Before deleting an unpublished module, verify:
- The module is not linked to any other module as a lookup.
- Workflow rules configured for this module have been deleted.
- No reports depend on this module.
To delete an unpublished module:
- In the Modules page, hover over the module.
- Click the Edit icon.
- In the Edit Module page, click Delete.
- Review the instructions in the confirmation dialog and click Yes, Delete now.
If the module has already been published, the delete option will not be available and you will see the message: "This module cannot be deleted as it is part of the published version of your application."
Packaged custom modules
Custom Modules are packagable components. When you publish your application, all custom modules (including their fields, layouts, and configurations) are included in that version.
To learn more about packaging behavior, refer to Components and Packaging in Zoho Vertical Studio.
Property | Upgrade Type | Subscriber Modify Access |
Module display label (singular and plural) | Upgradable | No |
Module API name | Locked* | No |
Module description | Upgradable | No |
Page layout (sections, field arrangement) | Upgradable | No |
Layout section order (packaged sections) | Upgradable | No |
Layout field order (system-defined fields) | Upgradable | No |
Layout activate/deactivate status | Non-Upgradable | Yes |
Layout permissions (profiles with access to the layout) | Non-Upgradable | Yes |
Custom fields | Upgradable | No |
Field properties (label, data type) | Upgradable | No |
Field Mandatory property | Upgradable | No |
Field Unique property | Upgradable | No |
Field Tooltip property | Upgradable | No |
Subforms | Upgradable | No |
Subform fields | Upgradable | No |
Lookup relationships | Upgradable | No |
Related list configuration | Upgradable | No |
Permissions and profile access settings | Non-Upgradable | Yes |
Workflow rules | Upgradable | No |
Module tab order | Non-Upgradable | Yes |
Module Visibility settings | Upgradable | No |
Organize Modules configuration | Non-Upgradable | Yes |
Pricing inclusion (whether the module is visible to subscribers) | Upgradable | No |
Important notes:
- *Locked: The Module API name can be updated before the module is published for the first time. Once the module is included in a published application version, the API name is permanently locked and cannot be changed by the developer or the subscriber.
- Custom modules are included in your application version and available to all subscribers based on your plan tier and whether the module is added to the pricing plan.
- Module Visibility controls where modules appear (Modules list, Web UI, Tab Menu, etc.). Changes to visibility are upgradable and apply to all subscribers during upgrade.
- Organize Modules configuration determines which modules appear in subscriber Organize modules lists. Only modules visible in all three standard UI locations (Modules list, Web UI, Tab Menu) appear here.
- Subscriber customizations in Organize modules (hiding/showing modules) are not upgradable and persist across application upgrades.
Publish and version upgrade behaviour
When you create a new custom module:
You create a Properties module in your real-estate application to track listings, availability, and pricing. Before publishing, you add it to your pricing plan. When you publish the new version, new subscribers signing up receive the Properties module as part of their organization. Existing subscribers who upgrade also get the module added to their org.
If you create a second module, Amenities, but forget to add it to the pricing plan before publishing, subscribers will not see Amenities in their organization even after upgrading. You will need to add it to the pricing plan and publish again.
When you modify a custom module:
You add a new field, Parking Slots, to the Properties module and update the layout to include it in the Property Details section. When you publish the updated version, all subscriber organizations receive this change during their next upgrade. Subscribers who have customized their Organize modules setting to hide Properties will still not see it after the upgrade. Their preference persists. Similarly, if you change the module order in Organize modules configuration, that change applies only to new signups. Existing subscribers keep their own module order.
When you add a lookup field:
You add a lookup field in the Properties module linking each property to a Contact record (the property owner). When you publish this change, all subscribers receive the new lookup field after upgrading. A Properties related list also appears in each Contact record, showing properties linked to that contact.
When you delete a custom module:
You can only delete a custom module before it has been published. If you created an Amenities module but have not published the application version yet, you can delete it. Once Amenities is part of a published version, the delete option is no longer available.
If you need to retire a published module, hide it from all Module Visibility locations. The module and its data remain intact in subscriber organizations, but it no longer appears in the UI.
Limits and scalability
Custom module limits are determined by your plan tier (Starter, Growth, or Scale). Your plan tier defines the maximum number of custom modules you can create in your application.
- Maximum custom modules per application: Varies by plan tier. Each custom module you create in the Developer Console reduces the total available for that tier.
- Maximum custom fields per module: Varies by plan tier. 300 fields in Scale
- Maximum lookup relationships per module: Varies by plan tier. 10 lookups in Scale
- Module name length: Maximum 30 characters (singular and plural combined)
- Workflow rules per module: Limited by plan tier
Refer to Plan Tiers - Features and Pricing for exact limits.
When you create a custom module in the Developer Console, that usage counts against your plan tier limit. The same limit applies to subscriber organizations using your application. This means if you create 5 custom modules in your Starter plan, you have used 5 of your available module slots, and each subscriber organization will also be limited to those same 5 custom modules (plus the 10+ standard modules).
Note: If your plan tier limit is reached, you cannot create additional custom modules until you either upgrade your plan or delete existing custom modules. Plan your module structure accordingly and consolidate fields when possible.