Start a layout change with a record-entry problem. “Make the form simpler” is difficult to test. “Let service reps enter the requested service and see the questions needed for that service” gives you a requirement, a sample record, and a way to check the result.
This walkthrough uses that fictional service-entry requirement. Use your own field names and test users. Check the saved configuration and records before making the form part of everyone's daily work.
Define the record-entry requirement
Write down who creates the record, who updates it later, and which decision each field supports. Ask the people doing the entry to show you a recent example. A field can look unnecessary to the creator while serving a real handoff requirement for another team.
For the example, suppose all requests need a service choice and a contact method. Installation requests need a site-readiness answer. Ongoing-support requests need a coverage description. Treat these as proposed business requirements, not built-in Zoho fields or behavior.
Create a requirements worksheet:
| Requirement | Who needs it | How you will test it |
|---|---|---|
| Service choice is clear | Everyone entering requests | Create each sample service request |
| Relevant questions are visible | The entering rep | Change the service and inspect the form |
| Sensitive fields respect access policy | Administrator and manager | Compare intended profiles |
| Existing records remain usable | Current record owners | Reopen representative older records |
| Handoff data survives conversion | Receiving team | Convert a controlled test record |
Decide how blank and unknown values should differ. If the rep does not know whether the site is ready, forcing a yes-or-no answer encourages inaccurate data. Your process might need an explicit unknown choice or a clarification task instead.
Separate the requirement from its implementation. “Capture a loss reason when a sale is lost” is a business requirement. Whether you use field configuration, conditional behavior, or a validation rule depends on the account and your intended enforcement. Keep the acceptance test independent of that choice.
Find the module's layout editor
First confirm the module you are changing. A record-entry layout, a search result, and a home page are different surfaces. Editing one because another looks wrong can leave the original problem untouched.
Zoho's UI comparison guide documents field and layout configuration through a module's sidebar More menu in NextGen UI. Open that menu from the intended module and locate its field or layout configuration.
If your interface uses Setup instead, check Zoho's help docs for the current module-customization route. Match the instructions to the UI your organization actually uses. Do not follow an older screenshot merely because it has a familiar Setup icon.
Before changing the form, record the layout name, module, existing sections, and relevant access assignments. Capture your own before-and-after screenshots for the review, using fictional or redacted data. Label them with the UI version and test profile so another administrator can understand what they show.
If you are trying to change a search layout, identify the result surface and check its own configuration docs. If the home page suddenly shows open activities, investigate that home-page configuration separately. Neither issue proves that the module's data-entry layout changed.
Arrange fields and sections
Group questions in the order the rep can answer them. For the service example, place basic request context before service-specific details. Keep labels plain enough that a new teammate can understand what belongs in each field.
Review existing fields before creating new ones. Two fields with nearly the same meaning can split reporting and make later cleanup harder. Inspect how the current field is used in records, reports, and automation before deciding to replace or reuse it.
Use a small build sequence:
- Confirm the intended field names and data meanings.
- Arrange the common questions in a clear section.
- Put service-specific questions where the entry flow needs them.
- Review any required-field or conditional behavior against the requirement.
- Preview, save, and open a representative record under the intended profile.
Distinguish appearance from permission. A field that is absent from one form is not necessarily inaccessible through every other route. Zoho documents that field permissions apply across layouts of the same module. Review permissions as their own part of the change.
Zoho also documents that removing a field from one layout does not remove it from another layout using it. Check the other forms before assuming you removed the field everywhere. Keep a list of the places where the same data must remain available.
The customization guide gives you broader planning context. If the problem is actually about where a type of record belongs, review the modules guide before adding more fields to the current form.
Choose layout rules or separate layouts
Use the smallest structure that expresses the real difference in work. Zoho's page layouts FAQ describes conditional layouts that vary displayed fields according to the service selected. That supports the basic service example, but it does not establish support for every kind of condition.
| Your requirement | Direction to evaluate | Main check |
|---|---|---|
| Same record type, different questions after a service choice | Conditional behavior within the form | Test each choice and the blank state |
| Different teams need distinct entry forms | Separate layouts with appropriate access | Test each team's assigned form |
| Same data, different visibility rights | Field and profile permissions | Test access beyond the visible form |
| Different visual presentation of the record | A presentation-focused design | Confirm the entry requirement is still met |
For a picklist-based requirement, test the exact controlling field and intended values. For a multi-select condition, check Zoho's help docs before committing to the design. The documented service example is not proof of every multi-select combination.
If you reach a layout-rule limit, check Zoho's current pricing page and help docs for your edition's allowance. Avoid designing around a remembered limit. Reassess whether repeated conditions express the same business rule and could be simplified without hiding required information.
If you plan to deactivate an old layout, account for its records. Zoho documents that deactivation prompts a transfer of existing records to another layout. Review those records against the destination form before taking that step. A cleaner layout name does not guarantee that every older record fits it.
Assign access and test conversion
Layout access can be assigned to profiles. Test with the actual intended profiles rather than using only an administrator account. An administrator's successful save is weak evidence that a rep can complete the same entry flow.
Prepare a test for a normal rep and a manager. For each, check the available form, visible fields, editable fields, and the saved result. Confirm the owner after creation. If mobile entry matters, test the actual mobile experience and default form in your account; check Zoho's help docs for supported behavior.
Use contrasting cases: installation with a site-readiness answer, support with a coverage description, and a request with an unknown service. Also reopen an existing record containing older values. Test what happens when you change the service after initially entering the request.
For lead conversion, write down the values that should survive into the intended destination records. Check the current field-mapping configuration, convert a controlled sample, and inspect the outputs. A correctly saved lead form does not prove its custom values reached the destination.
If a test fails, identify whether the problem is layout access, field permission, conditional behavior, or mapping. Change one cause at a time and repeat the failed case. Preserve your expected results so the review stays tied to the original requirement.
Build the same layout with the AI Assistant
Give the Zoho CRM AI Assistant a complete requirement:
In the identified module, prepare a service-request layout using the existing fields listed below. Everyone needs service choice and contact method. Installation needs site readiness; support needs coverage description. Preserve the stated field permissions and assign layout access to the named profiles. Show the configuration plan before changes, then help test the sample records and conversion mappings.
The Assistant can carry out CRM configuration on request, including fields, layouts, validation rules, workflows, and functions. It applies the proposed layout and related CRM changes after your approval. Use the custom-field example or validation-rule example when a requirement needs a separate setup action.
Review the proposed change against your worksheet before approval. After the change, inspect the saved layout, access assignments, and test records. Have the reps complete the entry task and explain any confusing question. The finished form should collect the information your next decision needs, with permissions and record handoffs checked alongside its appearance.