A module should represent something your team needs to manage. Before creating another one, decide whether the information describes an existing record or needs its own owner, relationships, and lifecycle.
This guide follows a prospect into customer and opportunity records, then considers a proposed Service Requests module. The example is a data-design exercise, not a claim that every account has the same modules or edition features.
Understand modules, records, and fields
A module organizes CRM data by entity or relationship. A record is an individual entry in that module. Fields hold the details of the entry. A lookup points to another module.
Zoho's account introduction explains these concepts. Use a simple model to make the distinction concrete:
| Concept in your process | Proposed place in the model |
|---|---|
| An unqualified inquiry | Lead record |
| A person you communicate with | Contact record |
| Their company | Account record |
| A potential sale | Deal record |
| A separate service request | Candidate related record |
Within the proposed service request, a requested date is a field. The request itself is a record. Its company relationship should identify the intended account, rather than merely repeat a company name as unconnected text.
Draw a sample before configuring anything. Write the person, company, sale, and request on separate lines. Add the relationships you expect to inspect. If you cannot say which company owns the request, the model is not ready for an import.
The product overview explains the broader sales context. Keep this design focused on what each record represents and how the next user will find it.
Choose the standard modules your process needs
Begin by inspecting the modules already in your CRM and how your team uses them. Names alone can be misleading if an earlier customization changed their meaning.
Follow a real business event. An inquiry arrives, a representative qualifies it, and the team identifies the person, organization, and opportunity to pursue. Write down where the inquiry information should remain and what should carry into the ongoing relationship.
Avoid storing the same opportunity in several places because different teams use different labels. Agree on the record that represents the sale, then decide what related information each team needs.
List activities separately from the business entities. A follow-up action may concern a contact and an opportunity, but it does not automatically justify another customer module.
Check edition availability for the standard modules you plan to use. Zoho's account introduction lists Quotes and Invoices for Professional, Enterprise, and Ultimate. Confirm current availability for your account before building a process around them. Do not assume every inventory or support-related module is present in every edition.
For each proposed module, identify its operating owner and the report it should support. If nobody can name the decision the data enables, reconsider whether to collect it.
Decide between a field, custom module, and team module
Start with a question: can an existing record contain the information without losing the history you need?
If an account has one current service preference, a field may be sufficient. If the same account can have several requests with different dates, statuses, and owners, separate request records are easier to reason about.
Use this decision table for the proposed Service Requests process:
| Requirement | Design to evaluate |
|---|---|
| One descriptive value on an existing entity | A field on that entity |
| Repeated entries with their own lifecycle | Related records in a suitable module |
| A shared business entity used across the organization | A custom organization module |
| Work intended for a particular team's scope | A team-module option, after checking current documentation |
Do not infer team-module capabilities from the name. Check Zoho's help docs for availability, supported relationships, access behavior, reporting, and administration in your account. Compare those answers with the shared request process before choosing.
For this example, suppose requests must be reviewed across sales and operations and each needs its own accountable owner. Evaluate a custom organization module against that requirement. First confirm that no existing structure already handles it appropriately.
Write down what you rejected and why. “A field loses repeated-request history” is useful reasoning. “A custom module is more flexible” is too vague to maintain later.
Create a custom organization module
Zoho documents building custom organization modules without programming. Its module customization guide explains the supported setup. Access to customization is controlled by the Module Customization permission.
Confirm that the intended administrator has that permission and that your edition supports the proposed design. Check Zoho's current pricing page and help docs for current availability and limits.
Prepare a field dictionary before opening the builder:
| Proposed detail | Decision to record |
|---|---|
| Request name | A clear naming rule people can recognize |
| Request category | Agreed choices and who maintains them |
| Requested date | Meaning of the date and how unknown values are handled |
| Status | Observable entry and exit conditions |
| Account relationship | Which account the request concerns |
| Contact relationship | Which person is responsible for the discussion |
| Ownership | Who is accountable for the next action |
These are suggested business requirements, not assumed default fields. Inspect what the chosen module already provides and add only what is missing.
Create the supported structure, arrange its layout around the user's task, and check a sample record before importing anything. Use add a custom field for a concrete request to configure the missing information.
Keep interface design separate from the data model. The layout guide helps place fields where people can use them. A neat layout cannot repair an unclear relationship or a duplicated entity.
Connect records and configure access
Custom modules can link to standard modules. Use supported lookups to express the relationships you need, then verify them on saved sample records.
For a service request, select the intended account and contact from actual CRM records. Open the account and compare its details with your test case. Similar company names are a reason to inspect the match, not a reason to accept the first result.
Check the related-record presentation available in your setup. Your acceptance criterion is practical: from the account, can the intended user find the relevant requests, and from the request, can they identify the correct company and person?
Review access with the administrator. Name the representative who should create a request, the operations user who should update it, and the manager who should review the work. Use who can see records to inspect the current configuration.
Test each role against the same sample. An administrator's successful edit does not prove the operations user can complete the process.
The same reasoning applies to a school model with parents and children. First decide whether each child has one relevant parent relationship or several. Specify how the parent record should show related children. Then check the supported relationship structure in Zoho's help docs. Do not assume a single lookup represents every family arrangement.
Review the model from the perspective of someone answering a customer question. Give a tester the company name and ask them to find all relevant requests, identify the open one, and name its owner. Then give them a request identifier and ask them to identify the correct contact. If either route requires searching unrelated notes, investigate whether the relationship or its presentation is missing.
Use a second request for the same account to test repeated records. Changing the second request's status should not be interpreted as changing the first request's status. Your acceptance checks should distinguish those individual lifecycles, not merely prove that a company has some service information.
Before release, ask the report owner to describe the unit they want counted. Requests, accounts with requests, and contacts involved in requests are different totals. Write that distinction into the report requirement while the model is still small enough to inspect manually.
Keep relationship definitions in the field dictionary. Future imports and reports need the same meaning as the initial configuration.
Ask the AI Assistant to build and inspect the model
The Zoho CRM AI Assistant can inspect existing modules and configure a supported CRM model on request. It can handle modules, fields, layouts, access configuration, workflows, Blueprint, Deluge functions, reports, imports, and cleanup. It makes changes only after your approval.
Inspect where we currently store service requests. Compare an existing field, a related-record structure, and a custom organization module against this process. Propose the smallest model that keeps repeated requests, their owners, and account/contact relationships clear. After approval, build the supported configuration in our test CRM, create sample records, and report their saved relationships and access checks.
Ask for a readable relationship report, such as:
| Sample | Expected relationship | Evidence to return |
|---|---|---|
| Request A | Intended account and contact | Saved identifiers and record links |
| Request B | Same account, different request | Distinct request with preserved relationship |
| Restricted-role test | Intended visibility | What the tested user can inspect or edit |
The entries above are expected checks, not completed results. Have the assistant return what it actually observed, including any unsupported feature or unresolved match.
Review the configuration and sample data separately. Approving a new lookup does not approve relinking every existing record. Keep a bulk cleanup request bounded by a reviewed list.
The assistant operates inside Zoho CRM. An external system owner must configure any corresponding objects outside CRM. If another application supplies requests, its owner must validate that application's identifiers and transfer behavior.
Use the customization guide when the model also needs validation or an owner follow-up process. Build those rules only after the underlying relationships make sense.
Test imports and avoid disconnected data
Before importing requests, prepare the accounts and contacts they should reference. Review existing entities so the import does not create another company merely because a name is formatted differently.
Map source columns deliberately. Write the destination field, data type, expected relationship, and treatment of blanks. For an existing match, decide whether to retain the CRM value, fill an empty field, or update a confirmed value.
Use import contacts without overwriting data when preparing people. For contacts already linked to the wrong company, use contacts under the wrong account to assemble a review list before correcting relationships.
Run a small sample covering a new request, another request for the same account, an existing person, and an unresolved company match. The sample size should be small enough that you can open every result.
Check the saved relationships from both directions. Confirm the request points to the intended account and contact, and that the intended user can find the related request from their normal starting record. Compare source and saved identifiers rather than relying only on display labels.
If a relationship is missing, inspect the mapping and source match before retrying. Reimporting unchanged rows can add confusion without fixing the underlying association.
Keep an import exception sheet with the source row, unresolved relationship, reason, and responsible reviewer. A row with a missing account match should remain visibly incomplete until someone confirms the destination. After correction, rerun only the reviewed exception and inspect its saved lookup. This prevents a later operator from treating a previously excluded row as a new entity merely because it was absent from the first result list.
Mapping fields between modules
Matching names are not a mapping specification. Record the source field, destination field, compatible type, transfer event, and expected blank-handling behavior. Check Zoho's help docs for the supported method in that particular process, then inspect the destination after a test.
A value visible in the source record is not proof that it has been copied to the destination. Decide which record owns later corrections so the two do not quietly diverge.
Moving or cloning a module
Treat moving records between custom modules as a migration project until the supported method is confirmed. Map the fields and relationships, prepare a sample, and compare the resulting records and access. Preserve source records until you have verified the destination and agreed on cleanup.
If you want to clone a module, check the current documentation for what the available operation copies. Configuration, data, permissions, and automation are separate questions. Do not assume that reproducing a module's label reproduces its complete behavior.
Finish with a relationship review your team can understand: which entities exist, where each is owned, how they connect, and which exceptions remain. That record is what makes the model maintainable when the next field, import, or report is requested.