CRM Custom Fields: A Practical Design Guide - Relaticle [ Back to blog ](https://relaticle.com/blog) ![How to design CRM custom fields your team will use](https://relaticle.com/storage/ink/01M34D9JFP41HRBX4Z79ZZRBT7.png) Design CRM custom fields around decisions your team makes, not every detail you could collect. Each field needs a clear meaning, a suitable type, and someone responsible for its quality. Start with a small field dictionary, test it on representative records, then verify the same values through your imports and integrations. We build configurable fields into Relaticle because different teams sell differently. A consultancy's project budget is not the same fact as a software company's annual subscription value. Both may belong in a currency field, but the definitions matter more than the widget. Use the field dictionary and worked example below to decide which fields to add. The example follows an illustrative consultancy preparing proposals. [](#begin-with-the-questions-your-team-already-asks "Permalink")Begin with the questions your team already asks --------------------------------------------------------------------------------------------------------------- Look at your last few sales conversations and pipeline reviews. Write down the questions that affected a decision. “Which proposals need a technical review?” suggests a useful field. “What else might we want someday?” does not establish a requirement. A field should support a repeatable use: filtering a work queue, grouping opportunities, assigning follow-up, or preserving a fact needed at handoff. If nobody can name the use, leave the detail in a note until the need becomes clear. Now identify where the answer belongs. A company's industry describes the company across opportunities. A project's expected start date describes one opportunity. A person's job title describes that person, even when they participate in several deals. Putting a fact on the wrong record creates unnecessary synchronization. If every opportunity repeats the company's headquarters address, a single change creates several competing answers. Prefer one owner for the fact, then use relationships to provide context. Relaticle has companies, people, opportunities, tasks, and notes. Start by choosing among those entities before adding a new field. Do not turn a custom field into a replacement for an existing relationship. [](#use-a-field-dictionary-before-using-the-builder "Permalink")Use a field dictionary before using the builder --------------------------------------------------------------------------------------------------------------- A field dictionary is a short agreement about meaning. It does not need a dedicated system. A shared document is sufficient while the schema is small. Give every proposed field these entries: ``` Label: Field code: Entity: Decision or workflow supported: Definition: Type: Allowed values: Meaning of an empty value: Source of truth: Person responsible: When people should update it: Example valid value: Example invalid value: ``` The definition should settle the disagreement most likely to appear later. For “Project value,” specify whether it means the initial engagement, annual value, or lifetime potential. State whether tax belongs in the amount. For “Expected start,” specify whether the date comes from the buyer or your delivery forecast. Those are different facts. Combining them produces a confident-looking date that nobody can interpret reliably. Treat the field code as part of an integration contract. Relaticle uses codes such as `close_date` and `job_title` in custom-field payloads. Choose a stable term rather than a temporary campaign name. A label can help people read the form. A code helps an integration identify the field. Record both so an import mapping does not depend on someone remembering which label changed last month. ### [](#worked-example-technical-review "Permalink")Worked example: technical review Here is a completed dictionary entry for the illustrative consultancy. It supports one decision: which proposals need an engineer before the team sends them. ``` Label: Technical review Field code: technical_review Entity: Opportunity Decision: Find proposals waiting for an engineer Definition: Review status of the current proposed scope Type: Single choice Allowed values: Not needed, Pending, Complete Empty value: Nobody has assessed whether review is needed Source of truth: The engineer's review note Person responsible: The person preparing the proposal Update when: Scope changes or the engineer completes review Valid example: Pending Invalid example: Nearly complete ``` A changed scope can make an earlier review obsolete. The proposal owner should return the field to Pending and explain the change in a note. Test the distinction between empty and Not needed. Empty enters the assessment queue. Not needed means someone assessed the proposal and explicitly ruled out technical review. [](#choose-a-type-that-preserves-the-question "Permalink")Choose a type that preserves the question --------------------------------------------------------------------------------------------------- Use the smallest type that represents the information accurately. A text box accepts almost anything, but that flexibility moves interpretation into every later report and integration. | Information | Useful starting type | Design question | |---|---|---| | Expected start | Date | Is the day meaningful without a time? | | Proposal value | Currency | What amount and currency convention does the team use? | | Buying stage | Single choice | Can each opportunity occupy exactly one stage? | | Required services | Multiple choice | Can more than one option be true? | | Confirmed requirement | Toggle | Does false mean no, or merely unknown? | | Discovery summary | Rich editor | Does this need narrative detail and formatting? | | Related record | Record link | Does the value identify an existing CRM record? | A date field should hold dates, not “early next month.” Keep an uncertain statement in a note until someone can provide an actual date. Inventing precision makes reminders and filters less trustworthy. For choices, distinguish categories from free-form tags. A controlled list supports consistent reporting. Tags suit evolving descriptive labels when variation is acceptable. Do not expect the same analytical precision from both. Salesforce's [custom-field introduction](https://trailhead.salesforce.com/content/learn/modules/custom-fields-quick-look/create-a-custom-field) makes the same foundational distinction between the information and its format. The exact field types differ by product, so verify the target CRM's available choices. Relaticle's [field-type guide](https://relaticle.com/help/custom-fields/field-types-you-can-add) documents its current options. FileUpload and MarkdownEditor are retired types. Use RichEditor for formatted content and supported attachments. [](#separate-unknown-from-no "Permalink")Separate unknown from no ----------------------------------------------------------------- A checkbox is useful when the distinction is genuinely binary. It is less useful when the team needs to distinguish “no” from “we have not asked.” Those answers lead to different next actions. Consider a field called “Budget approved.” An unchecked value might mean the buyer rejected the budget, the seller forgot to update it, or nobody asked. A four-option choice can make those states explicit: Unknown, Under review, Approved, Declined. Unknown means nobody has established the answer. Declined records an explicit refusal. Do not add an Unknown option automatically to every list. Sometimes an empty value already has a clear meaning. The important part is agreeing on that meaning and preserving it across entry paths. Document clearing behavior too. In Relaticle updates, omitting a field means leave it unchanged. Explicit `null` clears an optional value, and multi-value fields can use an empty array. Required-field validation may reject clearing. That distinction matters during migration. A source export may contain empty cells because the source never collected the information. Decide whether those cells should clear destination values or leave them untouched before running updates. [](#build-a-starter-schema-for-one-real-workflow "Permalink")Build a starter schema for one real workflow --------------------------------------------------------------------------------------------------------- Suppose a small consultancy reviews proposals every Monday. It wants to identify work that needs a technical review and confirm whether a delivery date is realistic. The following example supports those decisions without attempting to describe the entire business. | Proposed field | Entity and type | |---|---| | Service line | Opportunity, single choice | | Technical review | Opportunity, single choice | | Expected start | Opportunity, date | | Amount (existing field) | Opportunity, currency | | Delivery requirements | Opportunity, rich editor | | Referral source | Company, text or choice | | Proposed field | Definition | |---|---| | Service line | The main service this proposal sells | | Technical review | Not needed, Pending, or Complete | | Expected start | The start date most recently discussed with the buyer | | Amount (existing field) | Proposed initial engagement value under the team's stated convention | | Delivery requirements | Requirements that affect scope or staffing | | Referral source | The agreed source of the company's introduction | The example reuses Relaticle's existing amount field and proposes the other fields. Relaticle also supplies opportunity stage and close date. Reuse existing fields when their meaning matches the decision. Notice the difference between close date and expected start. One concerns winning the engagement. The other concerns delivery. A single date cannot answer both questions without changing meaning between readers. Also notice what the example omits. It does not add separate fields for every sentence in a discovery call. Narrative requirements stay in one rich-editor field until a recurring decision needs more structure. [](#make-choices-distinct-and-recognizable "Permalink")Make choices distinct and recognizable --------------------------------------------------------------------------------------------- A choice list becomes difficult when options overlap. “Partner,” “Referral,” and “Agency referral” may all describe the same introduction. People will select different answers while believing they are following the rules. Write a short definition for every option. Test whether someone can classify the same example consistently. If two options fit, refine the categories or acknowledge that multiple selection is the correct model. Avoid labels that differ only through abbreviations or capitalization. “Enterprise,” “ENT,” and “enterprise” should not become three reporting categories. Import mappings should normalize those source values deliberately. Keep labels distinct within a field. Relaticle accepts choice labels or option IDs through its shared input normalization. An ambiguous label cannot identify one option reliably. Stable IDs help integrations, while distinct labels help people and assistants. When changing options, inspect stored values and dependent workflows first. Do not assume renaming, merging, and deleting an option have identical effects. Test the actual change on representative records before applying it broadly. [](#add-required-fields-only-when-the-answer-exists "Permalink")Add required fields only when the answer exists --------------------------------------------------------------------------------------------------------------- A required field can prevent incomplete records. It can also force people to invent an answer before the sales process has produced one. That replaces a visible gap with unreliable data. Ask when someone can reasonably know the answer. A company name is available at creation. A confirmed implementation date may remain unknown until later negotiations. Treat those moments differently in your operating process. Start optional when uncertain, then inspect actual usage. If a field becomes essential to every relevant record, discuss whether validation should enforce it. The validation must match what people can truthfully supply. Do not assume the CRM supports a field that becomes required only in one stage. Verify that behavior before building a process around it. A written stage checklist is preferable to claiming conditional enforcement that the application does not provide. For migration work, required fields deserve explicit mapping tests. A target schema can reject rows that the source CRM accepted. Our [CRM migration guide](https://relaticle.com/blog/migrating-from-hubspot-or-attio-to-a-self-hosted-crm) covers the broader transfer process. [](#test-each-field-through-every-entry-path "Permalink")Test each field through every entry path ------------------------------------------------------------------------------------------------- A field that works in a form may still expose a mistaken assumption in an import or integration. Create a small acceptance set before asking the whole team to use the schema. Include a normal value, an empty value, a value that should fail, and a value near a meaningful boundary. For currency, that might include decimals. For choices, include an unfamiliar source label. For dates, include a value whose day and month could be confused. 1. Enter a valid value in the web form and read it back. 2. Update the same field through the integration you expect to use. 3. Clear an optional value and verify it disappears. 4. Submit an invalid value and inspect the error. 5. Confirm filtering and exported values match the team's interpretation. Relaticle discovers active custom fields dynamically for the API and agent surfaces. That removes per-field integration code, but it does not decide your business meaning. Our [shared custom-field architecture](https://relaticle.com/blog/custom-fields-that-work-everywhere-without-per-field-code) explains the persistence and validation path. Use the [API reference](https://relaticle.com/developers/api) when testing external writes. Retrieve the current schema instead of guessing codes from display labels. Keep failed cases in your migration checklist so corrections remain reproducible. [](#review-the-schema-after-people-use-it "Permalink")Review the schema after people use it ------------------------------------------------------------------------------------------- Schedule a short review after the first few operating cycles. Bring examples of records that were difficult to classify. A discussion around actual records produces better definitions than a debate about abstract completeness. Look for fields nobody uses, options that mean the same thing, and answers that change between teams. Also inspect fields populated mostly with defaults. A filled column can hide the same uncertainty as an empty one. Assign each issue to a definition, a type, an option list, or a workflow expectation. Do not respond to every ambiguity by adding another field. Sometimes the correct fix is a clearer definition or a narrower question. Retire fields deliberately. Deactivation in Relaticle blocks new writes, but it is not a confidentiality boundary. The chat schema can still describe inactive fields. Review permissions separately when the underlying information needs restricted access. Keep the field dictionary current when meaning changes. Your team should be able to answer what a field means without asking the person who first created it. That is the standard worth using before adding the next one. Tagged: [ #mcp ](https://relaticle.com/blog/tag/mcp) [ #migration ](https://relaticle.com/blog/tag/migration) Related posts ------------- [ Guides Oct 27, 2026 Sales pipeline stages for small B2B teams ------------------------------------------- Sales pipeline stages for small B2B teams, with a six-stage template, three worked decisions, and clear rules for stalled proposals and verbal agreements. ![Sales pipeline stages for small B2B teams](https://relaticle.com/storage/ink/01M34D3CNENN8NAZ9B0DY4AP2K.png) ](https://relaticle.com/blog/sales-pipeline-stages-for-small-b2b-teams) [ Guides Oct 23, 2026 AI CRM evaluation: tests to run before moving data ---------------------------------------------------- An AI CRM evaluation kit with fictional records, three prompts, an answer key, and separate approval checks for built-in chat and external MCP clients. ![AI CRM evaluation: tests to run before moving data](https://relaticle.com/storage/ink/01M38HXRE27ZBW8HW6D0VPVRFP.png) ](https://relaticle.com/blog/how-to-evaluate-an-ai-crm) [ Guides Oct 20, 2026 CRM for agencies: buyer checklist and client handoff ------------------------------------------------------ Choose a CRM for agencies by testing client history, repeat engagements, follow-up ownership, and a completed sales-to-delivery handoff. ![CRM for agencies: buyer checklist and client handoff](https://relaticle.com/storage/ink/01M38HHKTE0MGM6TJB4FPDTWZH.png) ](https://relaticle.com/blog/crm-for-agencies-from-first-call-to-project-handoff) ### On this page