A small distributor wants to know which customers need a site survey before a quote. Its spreadsheet contains columns called Site, Ready, Survey, Notes 2, and Priority. Different sellers interpret those headings differently. Recreating them as CRM fields would preserve the confusion. Designing a schema starts by asking what the team needs to decide, which facts support that decision, and how someone can record those facts without guessing.
A CRM with custom fields gives a business room to represent its own selling process. That flexibility can support a clear workflow or produce a crowded form where unrelated facts compete for attention. The difference often comes from small design choices: a date instead of text, a relationship instead of a copied name, an explicit unknown state instead of a misleading default.
This guide focuses on building the first useful schema. It follows a business that sells installation services and needs to prepare accurate quotes. The examples are intentionally ordinary: survey requirements, site readiness, service preferences, and quotation constraints. Use the method with your own decisions, then test a few realistic records before importing a large dataset or adding automation.
Match the fact to the type of value it really is
The right type makes entry, filtering, and later updates easier to interpret.
| Fact | Possible field type | Why the distinction matters |
|---|---|---|
| Survey needed? | Defined single choice | Unknown, required, and not required are different states |
| Survey appointment | Date and time | An exact appointment differs from an approximate month |
| Site contact | Relationship to a person | The contact remains identifiable when their name changes |
| Requested services | Multiple choice or related service records | Several services may apply without inventing compound labels |
| Access instructions | Text | Useful details cannot always be reduced to a controlled category |
| Quoted floor area | Number with a defined unit | A calculation needs a consistent quantity and meaning |
Begin with a decision and a sample of real records
Choose one recurring decision such as Can we prepare this quote? Ask the person doing the work which facts they need: location, requested service, approximate size, access restrictions, survey requirement, and the customer’s desired timing. Then inspect ten recent requests. Include complete, incomplete, unusual, and abandoned examples. The sample reveals which information is routinely available and which values users would have to invent to complete a form.
For every proposed field, name the reader as well as the writer. A seller may capture the preferred visit day so an operations coordinator can schedule a survey. If nobody can explain who will use a value, defer the field. This is a design filter, not a demand that every customer detail fit a structured field. Context that supports understanding can remain in a concise note until a repeated decision justifies structure.
Put the fact on the record it describes
A preferred contact method belongs to the person if it applies to their communication generally. A requested installation date belongs to the opportunity or job, because the same customer may have several requests. A site access rule may belong to a site record when multiple jobs use the same location. Placing the fact on the wrong record forces the team to overwrite it or create duplicate people and companies to hold separate situations.
Use a practical test: can two simultaneous pieces of work for the same customer need different values? If yes, a company-level field may be too broad. Conversely, if the fact remains true across every opportunity, copying it into each deal adds maintenance. A small team can begin with standard records and add a custom object only when repeated relationships cannot be represented clearly with the available structure.
Choose types that preserve the meaning of unknown
A checkbox works well when checked and unchecked have a complete, shared meaning. It works poorly when an unchecked value could mean No, Not asked, or Imported without an answer. For a survey requirement, a choice such as Unknown, Required, and Not required makes the uncertainty visible. The next action for Unknown is to confirm the requirement; the next action for Required is to arrange the survey.
Dates also need careful meaning. If the customer says sometime next quarter, do not invent an exact date merely because the form requires one. Capture the time window in an appropriate field or keep the estimate separate from a confirmed appointment. Numeric fields need units: floor area in square metres cannot safely share a column with square feet. Money needs currency context, especially when records will be added or compared.
Write options that support a decision without encoding everything
A single-choice field should describe one dimension with options that users can distinguish. Site readiness might use Not assessed, Ready, Work required, and Waiting for access confirmation. Avoid options such as High priority customer waiting for survey, which combine urgency, customer importance, and workflow state. Those combined values are hard to filter and become impossible to maintain as more exceptions appear.
Decide whether several options can be true at once. A customer can request installation and maintenance, so a service-interest field might allow multiple selections. But a quote cannot normally be both Approved and Declined as its current decision state. If individual services need separate quantities, prices, or dates, a multi-choice field may be insufficient; related service items may be a better model. Let the business question determine the structure.
Use relationships for identities and text for explanation
A field called Survey owner that stores a person’s name as plain text cannot reliably distinguish two people with the same name or follow a name change. When the value identifies a workspace user or another CRM record, use the supported relationship type. The visible label may be friendly, but the stored reference should identify the exact record. This matters when a workflow assigns responsibility or a report groups work by owner.
Text remains the right choice for context such as Gate closes at five; call the site contact before arrival. Do not force every useful explanation into options. Pair a structured blocker category with a short description when both routing and nuance matter. In a practical form, the category helps a queue find the work, while the explanation lets the next person complete it without asking the customer to repeat themselves.
Require information when it becomes knowable
A new inquiry rarely arrives with a confirmed budget, final scope, installation date, and every stakeholder. Requiring all of them at creation encourages placeholder values. Instead, identify what is necessary to save an inquiry, prepare a quote, approve a proposal, and hand work to delivery. Stage-specific completeness can be a process check even when the CRM does not support conditional requiredness directly.
Defaults deserve the same scrutiny. Defaulting every imported inquiry to Survey not required may hide risk; defaulting a requested date to today can distort urgency. Use defaults for values that are reliably true, not for fields the team dislikes leaving empty. If a system requires a value before the business knows it, revise the field design or the timing of record creation rather than teaching users to enter information they expect to correct later.
Write a compact field specification and test it in the interface
For each field, write its label, record type, data type, accepted values, one valid example, one invalid example, and the decision it supports. Define whether an empty value is meaningful and who can answer the question. A compact specification lets the person configuring the CRM and the person importing data make the same choices. It also makes disagreements visible before the team has hundreds of records to clean up.
Then enter several records using the actual form. Ask a colleague to add an inquiry from a brief email, update a survey result, and find quotes that are ready to prepare. Check the field labels in tables and filters, not only on the configuration screen. A label that makes sense inside a section called Survey may be ambiguous in a standalone report. Adjust wording while the sample is still small.
Import with explicit mappings and reserve formulas for derived values
Map each source column to the chosen destination and normalize values before a broad import. Ready, YES, and good to go may all mean one site-readiness option, but confirm that interpretation with the people who entered them. Keep an exception list for ambiguous values. Test dates, empty cells, decimal separators, and repeated relationship names in a small sample; an apparently successful import can still put the wrong meaning into a valid field.
Separate observed facts from calculations. A formula can derive an estimated service total from defined inputs, but the customer’s approved amount is a different fact. Avoid making users enter a derived value twice. Intelligent CRM documents custom fields, custom objects, and formula fields as Pro capabilities; inspect the supported types and formula behavior in your workspace before implementing this example. The schema should remain useful even before any automatic calculation is added.
Replace five ambiguous columns with a short, usable design
An illustrative installation team replaces Ready with Site readiness on the deal, using Not assessed, Ready, and Work required. Survey required becomes a separate three-state choice. Survey appointment is a date-time field, Site contact is a person relationship, and Access instructions is text. Requested service uses a defined choice list. The team leaves future installation timing as an unconfirmed window until a specific date is agreed. Its quote-preparation view includes deals with a confirmed service and completed survey or an explicit decision that no survey is needed.
A coordinator can now distinguish a missing assessment from a confirmed blocker without opening every note. The seller knows which question remains unanswered, and the survey contact can be reached through the linked person. Before migration, the team tries the design against ten old inquiries and adjusts two labels that colleagues interpret differently. It also checks that an unknown survey requirement stays out of the ready-to-quote view.Custom-field design checklist before importing data
- Name the decision each structured field will support.
- Identify who supplies the value and when they know it.
- Put opportunity-specific facts on the opportunity.
- Separate unknown values from confirmed negative answers.
- Define units, currency context, and date precision.
- Keep each choice field focused on one business dimension.
- Use relationships when a value identifies another record or user.
- Test labels in forms, filters, tables, and reports.
- Map ambiguous source values before a broad import.
- Keep calculated estimates separate from customer-approved facts.
A small schema can be precise without becoming complicated
The best starting point for CRM custom fields is a real decision and a few representative records. Correct placement, meaningful types, explicit uncertainty, and understandable options make those records useful long before a team adds elaborate automation. A field earns its place when it captures something a colleague can use without reconstructing the original conversation.
Build the smallest schema that supports the selected process, test it with the people who will enter and read the data, and migrate a sample before committing the full history. Good field design makes later reporting and workflow configuration easier because the underlying facts already mean what the business thinks they mean.