FAQs: Creating layouts and understanding layout rules | Zoho Desk

FAQs: Layouts and layout rules

Layout Fundamentals

What is a layout?
A layout controls how fields and sections are arranged on a module page within a department. It determines which standard and custom fields appear, their order, and whether individual fields are visible, read-only, or mandatory.

Layouts can be used for modules such as Tickets, Tasks, Accounts, Contacts, Activities, Products, and Time Entries.

For example, a warranty-support layout can include fields such as Purchase Date, Product Model, and Serial Number, while a billing-support layout can instead emphasize Invoice Number, Billing Address, and Payment Reference.
Why should an organization use multiple layouts instead of one large form?
Multiple layouts prevent agents and customers from having to work through fields that do not apply to their request. Rather than placing every possible field on a single form, separate layouts can collect only the details needed for a specific product, service, or process.

This reduces irrelevant data entry and helps agents obtain the information needed to resolve requests faster.

For example:

  1. A hardware-support ticket can request device model and serial number.
  2. A delivery-related ticket can request ZIP code and delivery address.
  3. A warranty request can request purchase date and proof-of-purchase details.
Can each department use a different layout?
Yes. Each department can have its own layouts, including its own combination of default and custom fields. Only departments to which a user has been added are available when that user creates or customizes layouts.

This is useful when departments follow different workflows. A Sales Support department may need account-related information, while a Technical Support department may require product and troubleshooting details.
What is the Standard Layout?
Every department has a Standard Layout for each applicable module. It is the default layout and cannot be deactivated or deleted.

Administrators can create additional layouts and choose which layout should be the department’s default. The Standard Layout remains available even after custom layouts are introduced.
Can a layout be reused rather than created from scratch?
Yes. A layout can be cloned within the same department or across departments. Cloning is useful when two processes are similar and only require a few field or section changes.

For example, an administrator can clone an existing “Consumer Product Support” layout into another department, then adjust the product-specific fields rather than recreating the structure manually.

Layout Availability and Assignment

Can agents choose a layout when creating a ticket?
Yes. Agents can select an appropriate Ticket layout while adding a ticket, provided the layout is assigned to their user profile.

Agents can create records only with layouts assigned to their profiles. Layout assignment should therefore reflect the work each profile is expected to perform.
Can customers select a layout when submitting a ticket?
Yes. Customers can select an appropriate Ticket layout when adding a ticket. However, only Ticket layouts can be made visible to end users in the Help Center.

Layouts for other modules are not described as being available to end users through the Help Center.
Can a layout be available to an agent who is not part of the department?
Yes. When adding a custom layout, an administrator can choose to allow non-department agents with the assigned profiles to access it.

This option should be used carefully. It can help shared-service teams handle specialized requests, but profile assignment and layout access should be reviewed to ensure the agent sees only the fields needed for their responsibilities.

Fields and Layout Behavior

Can the same field be required in one layout and optional in another?
Yes. Ticket properties including mandatory fields are configured at the layout level rather than globally at the department or organization level.

For example, Purchase Date can be mandatory in a warranty-claim layout but optional in a general product-question layout.
Can field visibility and editing behavior differ by layout?
Yes. Layouts determine whether fields are visible, read-only, or required. This allows the same field to serve different purposes in different workflows.

For instance, an internal escalation layout might display an approval reference as read-only, while a supervisor-facing layout permits authorized users to enter or update it.
What happens when a field is removed from a layout?
A layout can be rearranged using drag-and-drop, including adding fields, removing unused fields, and changing their order. Administrators should confirm that removing a field does not prevent users from supplying information required by that workflow.

A field that is necessary for a particular process should remain on the applicable layout, even if it is omitted from other layouts.
How many fields can a single layout contain?
Each layout can include up to 400 fields. The limit includes both standard and custom fields, regardless of field type, and applies across modules.

If a layout approaches this limit, create more focused layouts for separate processes rather than continuing to expand one form.

Layout Rules

What is a layout rule?
A layout rule allows the displayed layout to change based on a selected field value or defined criteria. It can guide users to a more relevant form when the information already entered indicates that a different process applies.

For example, a customer can select one or more service topics and then be directed to a layout that requests billing details when the selection indicates a billing-related need.
Can a layout rule use a multi-select picklist field?
Yes. Administrators can select a multi-select picklist when creating a layout rule.

For example, an organization can use a Service Topics multi-select picklist. When a customer selects relevant topics, such as billing-related topics, the rule can display a Billing Details layout that collects the required information.
Can layout rules validate a text format using regular expressions?
Yes. Layout-rule criteria can use:
  1. Matches Regex
  2. Not Matches Regex
  3. Contains Regex
For example, an administrator can use Matches Regex for an Order Number field to require an alphanumeric format such as ORD123. After valid information is entered, a layout such as Billing Details can be displayed.
When should a layout rule be used instead of creating a separate department?
Use a layout rule when requests belong to the same department but need different information based on the product, service, issue type, or process selected by the user.

Use separate departments when the work itself requires distinct departmental organization. Layout rules customize the form experience; departments organize the help desk’s operational structure.

For example, one Technical Support department might use separate layouts for software incidents and hardware repairs. A completely separate Billing department may be appropriate when billing work requires its own departmental structure.
What should be planned before configuring layout rules?
Before creating a rule, define:
  1. The deciding field - Identify the picklist, multi-select picklist, or text field whose value should drive the rule.
  2. The target layout - Create a layout containing only the fields required for that scenario.
  3. Mandatory fields - Confirm that fields are required only where they are necessary.
  4. Profile assignment - Ensure the appropriate agents can create records using the target layout.
  5. End-user visibility - If customers must use the layout in the Help Center, ensure it is a Ticket layout and is available to end users.
  6. Validation criteria - For structured values such as order numbers, define whether regex-based criteria are needed.

 Design and Governance

How should layouts be designed for customer-facing ticket forms?
Customer-facing layouts should request only the information needed to classify and resolve the request. Avoid exposing a long list of fields intended for unrelated products or processes.

A practical design approach is:
  1. Start with the customer’s request type.
  2. Identify the minimum information needed for routing and resolution.
  3. Create a targeted Ticket layout.
  4. Make only necessary fields mandatory.
  5. Test the layout as an end user and as an agent.
  6. Use a layout rule when a selection should lead to a more specific form.
For example, a customer selecting “Warranty Claim” may need to provide purchase date and product details, whereas a customer selecting “Account Access” should instead see fields relevant to login or account issues.
What is the main risk of creating too many layouts?
Excessive layouts can become difficult to maintain, can complicate profile assignment, and can make it harder for agents and customers to select the correct form. They are also subject to active-layout limits.

Create a new layout when the field set or workflow is meaningfully different. Use layout rules to guide users to the right layout where possible, and clone an existing layout when the new process is largely similar.