Layouts
Layouts define how fields, sections, and record details appear in a module. You use them to support multiple processes inside one module without duplicating module structure. Each layout can hold a different field setup, different section structure, and different process-specific behavior. This helps teams enter only the data relevant to their role while still working in the same module.
For example, in a Properties module, you can create one layout for Commercial properties and another for Residential properties. The commercial layout can show fields such as lease term, floor area, and business zoning, while the residential layout can show fields such as number of bedrooms, parking type, and furnishing status.
Layouts are packagable components. When you publish your application, layouts are included in that version and are available to subscriber orgs during signup or application upgrade. You can also use profile assignment and default layout settings to control which layout a user sees first during record creation.
For more details, refer to Working with Page Layouts and FAQs on Page Layouts. The same layout concepts and configuration flow apply in Vertical Studio applications.
To access and configure layouts:
- Sign in to your Developer Console.
- Open your application and click Edit.
- Go to Build > Modules.
- Select the module where you want to manage layouts.
- Open the Layouts tab.
- Click New Layout.
- Add sections, fields, and layout permissions.
- Click Save Layout
Core layout components
- Layout name
- Field and section arrangement
- Field property behavior in that layout
- Layout permission mapping
- Dependency field mapping
- Lead conversion mapping
- Profile assignment and default layout assignment
Sample use case
In an Automotive Platform application, the Deals module supports two processes: Vehicle Sales and Service Contracts. Sales teams need fields such as financing preference and delivery date, while service teams need fields such as warranty status and next inspection milestone. You create two layouts in the same module and assign profile access to each team.
After publishing, subscriber orgs receive both layouts. Users can choose or default into the correct layout during record creation from UI, import, web forms, and API flows. The system-generated Layout field can then be used in workflow criteria, assignment logic, custom views, and reports.
Packaged layouts
A Packaged Layout is a layout created in the developer console and included when you publish your application.
Subscriber orgs receive packaged layouts during signup or when they upgrade to a version containing layout changes.
Subscribers can use packaged layouts for record creation and record management. What subscribers can update locally depends on property-level packaging behavior.
To learn more about how packagable components work, refer to Components and Packaging in Zoho Vertical Studio.
Packaging behavior
The following table describes the validated packaging behavior for layout properties.
Property | Upgrade Type | Subscriber Modify Access |
Name | Upgradable | No |
Fields | Upgradable | No |
Mandatory Status | Upgradable | No |
Unique Status | Upgradable | No |
Sections | Upgradable | No |
Profile assignment | Non-Upgradable | Yes |
Default layout assignment | Non-Upgradable | Yes |
Status | Non-Upgradable | Yes |
Module permission | Non-Upgradable | Yes |
Map dependency fields | Non-Upgradable | Yes |
Lead conversion mapping | Non-Upgradable | Yes |
Upgrade behavior:
Action | Upgrade outcome for existing subscriber orgs |
Create a new layout in the developer console | Added during upgrade |
Update layout name | Applied during upgrade |
Edit layout structure and field behavior | Applied during upgrade |
Activate a layout in the subscriber org | Subscriber setting persists after later application upgrades |
Deactivate a layout in the subscriber org | Subscriber setting persists after later application upgrades |
Update module permission mapping | Not applied during upgrade |
Update dependency field mapping | Not applied during upgrade |
Update lead conversion mapping | Not applied during upgrade |
Delete a layout in the developer console | Removed during upgrade after record transfer |
Publish and version upgrade
Scenario 1: You publish a new version and a subscriber signs up
Behavior: When you publish a new version, a new subscriber org receives all packaged layouts that exist in that version.
Example: You publish a version that includes Vehicle Sales and Service Contracts layouts in the Deals module. A new subscriber signing up on that version receives both layouts immediately.
Scenario 2: You rename a layout or add a new section
Behavior: When existing subscriber orgs upgrade, they receive upgradable layout changes such as a layout rename or an added section.
Example: You rename Vehicle Sales to Retail Vehicle Sales and add a new section in that layout. Existing subscriber orgs receive both changes after upgrade.
Scenario 3: You rename a layout and update module permission mapping
Behavior: When existing subscriber orgs upgrade, they receive the upgradable changes, but non-upgradable changes are not applied.
Example: In one release, you rename a layout and also update module permission mapping. During upgrade, existing subscriber orgs receive the new layout name, but they keep their current module permission mapping.
Scenario 4: You update dependency mapping or lead conversion mapping
Behavior: Module permission, dependency mapping, and lead conversion mapping changes are non-upgradable. Existing subscriber orgs retain their current configuration. New subscriber orgs receive the latest published configuration.
Example: You update dependency mapping and lead conversion mapping for the Service Contracts layout. New subscribers signing up after publish receive the updated mappings. Existing subscribers keep their previous mapping settings unless they update them in their own org.
Scenario 5: You delete a packaged layout
Behavior: Layout deletion requires record transfer to another layout before deletion can complete. During transfer, records are remapped to fields in the target layout. Fields that only existed in the deleted layout move to Unused Fields. Existing subscriber orgs lose the deleted layout during upgrade.
Example: You delete the Legacy Service layout and transfer its records to Service Contracts. Records move to the target layout, layout-specific orphan fields move to Unused Fields, and existing subscriber orgs no longer see Legacy Service after upgrade.
Scenario 6: A publish diff shows unexpected layout edits
Behavior: A layout can appear as edited in publish diff even when you did not manually rearrange sections. This usually happens because a dependent layout artifact changed, such as a field property, pick list option set, or layout permission mapping.
How to verify:
- Open the layout and check whether section order, field order, or field visibility changed.
- Compare field properties changed in the same release, for example Required, Read Only, or pick list options.
- Confirm whether any other dependent configuration in the same module changed field behavior.
Example: You update pick list options and another dependent setting in Vehicle Sales. Publish diff marks the layout as edited. Layout structure is unchanged, but field behavior changed through dependent configuration.
Changes and impacts
Delete layout
Deleting a packaged layout is a destructive change. Even with record transfer, users in subscriber orgs can lose layout-specific process context, field placement familiarity, and criteria behavior tied to that layout.
Use a staged rollout:
- Create and publish a replacement layout.
- Validate workflow criteria, assignment rules, and reports using the replacement layout in a test subscriber org.
- Transfer records from the old layout to the replacement layout.
- Publish deletion only after validation is complete.