Mapping Intake Fields to Clio Custom Fields: 2026 Guide

TL;DR

Mapping intake fields to Clio custom fields means connecting questions on an intake form to structured contact or matter fields in Clio so answers become searchable, reportable, automatable data instead of sitting trapped in a PDF or note. Only certain field types are compatible (date to date, dropdown to picklist, checkbox to yes/no), and paragraph text, multi-select, file attachments, and section breaks cannot be mapped at all. The best approach is to design fields backward from your documents, reports, and workflows, then build intake questions around those fields. Getting this right eliminates duplicate data entry, powers document automation, and makes every intake answer actually useful.

What Does Mapping Intake Fields to Clio Custom Fields Mean?

Think of the intake question as the front-end prompt and the Clio custom field as the back-end storage location. Mapping is the connection between them.

An intake field is any question or input on an intake form. “What was the date of the accident?” is an intake field. “Do you have a police report?” is an intake field.

A Clio custom field is a structured data slot that captures information beyond what Clio’s standard contact and matter fields provide. Clio defines custom fields as additional fields of information a firm needs for contacts or matters that are not part of the default setup. Custom field sets group these fields by practice area or workflow.

Mapping is the act of linking one to the other. In Clio Grow, this happens when you edit an intake form question, open Question settings, select “Connect to custom field,” and choose whether the destination is a contact custom field or a matter custom field. Once mapped, the prospect’s answer fills that Clio field automatically instead of living only as a form response.

Here is a simple example:

• Intake field: “What was the date of the accident?”
• Clio custom field: “Accident Date” (matter-level, date type)
• Mapping: The answer from the form fills the “Accident Date” field on the matter

Without this connection, intake answers require manual retyping into Clio. With it, the data flows in clean.

For firms exploring how AI tools can capture and route intake answers directly into Clio, automated legal intake platforms make this mapping even more critical.

Why Mapping Matters in Legal Intake

Mapping intake fields to Clio custom fields is not an admin checkbox. It is data architecture that determines whether the firm can actually use what it collects.

It reduces duplicate data entry. An ABA Law Practice Magazine article summarizing Clio’s 2024 secret-shopper study found that only 40% of law firms answered phone calls, down from 56% in 2019. The same article notes that manual data entry increases error risk and wastes staff time. When intake fields map directly to Clio fields, the firm eliminates one of the biggest sources of that waste.

It supports routing and qualification. A dropdown field for “Practice Area” or “Matter Type” lets intake staff or automation systems route leads to the right attorney immediately. A paragraph answer requires someone to read it first.

It powers document automation. Clio’s 2025 Legal Trends Report quotes a mid-sized family law firm that uses case-type-specific custom fields to populate autogenerated documents. When a file opens, the firm fills a set of custom fields and those fields drive generated pleadings, retainers, and letters. That only works if intake answers landed in structured fields from the start.

It improves reporting. You can filter matters by injury type, jurisdiction, referral source, or visa category, but only when those answers exist as structured field values, not buried in notes.

It supports consistency. Dropdown and checkbox fields force consistent values. Free-text answers produce “car accident,” “auto accident,” “MVA,” and “motor vehicle collision” for the same event. Good reporting requires consistent inputs.

Growing firms use more of this. Clio’s 2025 Legal Trends Report found that growing firms using Clio Grow use 15% more of the software’s functionality than stable firms and 44% more than shrinking firms. Intake field mapping is part of that usage gap.

Which Clio Grow Intake Fields Can Map to Custom Fields?

Most mapping problems are type mismatch problems. Clio only shows custom fields as selectable mapping options when the field type matches the intake question type. Here is the compatibility breakdown:

Clio Custom Field Type	Compatible Intake Question Type	Practical Use	Watch Out
Single-line text	Single-line text, multiple choice, dropdown	Claim number, A-number, short case fact	Too much free text creates inconsistent reporting
Date	Date	Accident date, arrest date, filing deadline	Use when deadlines or date sorting matter
Checkbox	Yes/no checkbox	Conflict checked, urgent, signed retainer, has insurance	Great for binary workflow triggers
Picklist / dropdown	Dropdown	Practice area, injury type, visa category, lead source	Custom field options override existing dropdown question options
Paragraph text	Not mappable	Narrative facts	Keep as form answer, matter description, or note
Multi-select	Not mappable	Multiple symptoms, multiple services	Consider separate checkbox fields or a narrative answer
File attachment	Not mappable	Police report, photos, medical records	Store as documents, not custom fields
Section break	Not mappable	Form instructions	Not data

Paragraph text, multi-select, section breaks, and file attachments cannot be connected to custom fields in the Clio Grow intake form builder. This is the single most common reason a custom field does not appear as a mapping option.

The Dropdown Override Rule

When you link a picklist/dropdown custom field to a dropdown intake question, Clio automatically populates the intake dropdown with the custom field’s picklist options and overrides any existing dropdown options you added to the question. Build the canonical list of choices in the custom field first. Do not maintain separate option lists in every intake form.

Contact Custom Fields vs Matter Custom Fields

Every mapped field must land somewhere. In Clio, that means choosing between a contact custom field (attached to the person or organization) and a matter custom field (attached to the case or engagement).

The simplest decision rule: Will this answer still be true if the same person opens a different matter?

If yes, it is probably a contact field:

• Preferred language
• Date of birth
• Pronouns
• Best contact method
• Company role

If no, it is probably a matter field:

• Accident date
• Arrest date
• Date of separation
• Court or jurisdiction
• Case type
• Insurance claim number
• Statute of limitations date

When the Answer Is a Person

Be cautious when the intake answer is another person’s name. A spouse, witness, doctor, beneficiary, trustee, or adverse party may need to be a related contact or a repeatable relationship structure, not just a text field. Practitioners on Reddit report that multiple-person scenarios are a common pain point in Clio setups, especially for estate planning and family law workflows where matters involve several named parties.

Will the Firm Report or Automate by This Answer?

If yes, make it structured. Use a dropdown, date, checkbox, or short text field. If no, the answer may belong in a note or narrative section. Avoid bloating Clio with fields nobody filters, reports on, or merges into documents.

For more on structuring intake around the right questions, see this guide to legal intake best practices.

Should You Create Fields in Clio Manage or Clio Grow First?

Officially, Clio lets you map intake questions to custom fields created in Grow or synced from Manage. But the practical answer from practitioners is clear: if the data must live in Clio Manage, Clio Draft, or matter reporting, design the field in Manage first.

A user in r/LawFirm shared that their automation goals failed when fields were created in Grow and did not import cleanly into Manage. Their conclusion was to create fields in Manage, sync to Grow, link the intake form fields, and then build automated documents.

Sync Limitations to Know

Not all Manage field types sync to Grow. According to Clio’s documentation, Contact Select, Matter Select, Integer, and Time custom field types do not sync from Manage to Grow. Design around these constraints. Do not build an intake workflow that depends on a field type Grow cannot receive.

Sync Direction Warning

Values edited in Clio Manage do not automatically sync back to Clio Grow. To keep custom field information consistent between the two, changes should be made in Clio Grow and then updated in Clio Manage. This one-way behavior catches many firms off guard.

Permission Requirements

Only users with administrator permissions can create, edit, or delete custom fields and custom field sets in Clio. Custom fields require Essentials, Advanced, or Expand subscriptions. If your custom field is not appearing, check both your permissions and your plan.

The 5-Layer Clio Intake Field Map

This framework helps you decide what kind of field each intake answer needs. Not every question deserves a mapped custom field, and not every answer should be an unmapped paragraph.

Layer 1: Identity Fields

Purpose: Identify the person or organization.
Examples: Name, email, phone, address, preferred language.
Where they belong: Standard Clio contact fields first. Only create contact custom fields when standard fields do not exist.
Rule: Do not create custom fields for data Clio already captures in standard contact fields.

Layer 2: Qualification and Routing Fields

Purpose: Decide whether the firm should take the case and who should handle it.
Examples: Practice area, matter type, jurisdiction, county, urgency, consultation type, adverse party known, conflict flag.
Where they belong: Matter custom fields, pipeline fields, or intake workflow fields.
Rule: Use dropdowns or checkboxes so intake staff and AI systems produce consistent values.

Layer 3: Case-Fact Fields

Purpose: Preserve facts the legal team will reuse.
Examples: Accident date, arrest date, date of separation, visa type, injury type, court, policy limit, employer name.
Where they belong: Matter custom fields, often grouped in practice-area custom field sets.
Rule: If a fact will appear in a pleading, retainer, demand letter, deadline calculation, or report, make it structured.

Layer 4: Relationship Fields

Purpose: Capture people connected to the matter.
Examples: Spouse, opposing party, witness, doctor, employer, adjuster, beneficiary, trustee, referring attorney.
Where they belong: Related contacts or carefully designed contact/matter fields.
Rule: A single custom text field may not be enough for witness lists, multiple beneficiaries, or co-fiduciaries. Plan for repeatable relationships.

Layer 5: Narrative and Evidence Fields

Purpose: Capture the client’s story, context, and documents.
Examples: “Tell us what happened,” uploaded police report, photos, medical records, timeline, client goals.
Where they belong: Form PDF, matter description, notes, documents, or unmapped narrative fields.
Rule: Do not force long narratives into structured custom fields. Clio’s intake builder does not allow paragraph text or file attachment questions to map to custom fields.

Practitioners on Reddit advise thinking through this structure before building anything. One commenter in a Clio community thread recommended deciding what the firm wants to measure before deciding what it tracks, and starting slowly rather than launching with 50 fields nobody uses.

Mapped Intake Field Examples by Practice Area

Abstract rules are easier to apply with concrete examples. Here is how mapping intake fields to Clio custom fields looks across four common practice areas.

Personal Injury

Intake Question	Destination	Field Type	Why
Date of incident	Matter custom field	Date	Limitation analysis and routing
Injury type	Matter custom field	Dropdown	Qualification, staffing, reporting
Police report available?	Matter custom field	Checkbox	Drives document collection
Insurance claim number	Matter custom field	Single-line text	Short reusable case fact
Describe what happened	Note / form PDF	Paragraph (unmapped)	Too narrative for a structured field
Upload police report	Documents / files	File attachment (unmapped)	Cannot map file uploads

PI firms need fast qualification and follow-up. The field map should support deadlines, document requests, and outbound follow-up. For more on structuring PI intake, see this guide to AI intake for personal injury firms.

Immigration

Intake Question	Destination	Field Type	Why
Preferred language	Contact custom field	Dropdown	Reusable across matters
Current immigration status	Matter custom field	Dropdown	Routing and case type
A-number	Matter or contact field	Single-line text	Short structured identifier
Date of last entry	Matter custom field	Date	Eligibility and timeline review
Country of citizenship	Contact or matter field	Dropdown	May be reusable or matter-specific
Immigration history	Note / narrative	Paragraph (unmapped)	Too detailed for structured mapping

Immigration intake often involves multilingual callers. A multilingual AI receptionist can capture these answers in the caller’s language, but the answers only become operationally useful when they land in the right Clio fields.

Family Law

Intake Question	Destination	Field Type	Why
Matter type	Matter custom field	Dropdown	Divorce, custody, support, adoption
Date of marriage	Matter custom field	Date	Pleadings and timelines
Date of separation	Matter custom field	Date	Documents and legal analysis
Children involved?	Matter custom field	Checkbox	Routing and follow-up questions
Opposing party name	Related contact or matter field	Text / related contact	Needed for conflicts
Describe your situation	Note / form PDF	Paragraph (unmapped)	Better for attorney review

Family law firms handling intake at volume can explore how an AI receptionist for family law can collect this structured data around the clock.

Estate Planning

Intake Question	Destination	Field Type	Why
Estate plan type	Matter custom field	Dropdown	Will, trust, amendment, probate
Married?	Contact or matter field	Checkbox / dropdown	Drives spouse-related questions
Spouse name	Related contact	Text / relationship	Multi-client matters require care
Children?	Matter custom field	Checkbox	Drives beneficiary questions
Fiduciary names	Related contacts or custom fields	Text / contact relationship	Avoid a single paragraph if used in documents
Special instructions	Note / narrative	Paragraph (unmapped)	Human review only

Community discussions around estate-planning setups repeatedly emphasize planning the field structure before building intake forms and document templates.

Common Mistakes When Mapping Intake Fields to Clio Custom Fields

The setup looks straightforward, but small mistakes compound across forms, templates, and integrations.

Mapping everything. Too many fields slow down intake and reduce adoption. The practical advice from r/clio is to start with what the firm wants to measure and add fields as needs emerge, not to begin with a large unused field library.

Mapping too little. If every answer goes into a paragraph field or PDF, the firm loses search, filtering, routing, reporting, and document automation value.

Using paragraph fields for structured data. Paragraph answers are fine for narratives (“Tell us what happened”). They are poor for deadlines, statuses, lead sources, case types, jurisdictions, or document variables. Clio reinforces this by not allowing paragraph text questions to map to custom fields.

Building dropdown options in the intake question instead of the custom field. When a picklist custom field is linked to a dropdown intake question, the custom field’s options override whatever you added to the question. Define the canonical list in the custom field.

Forgetting to reconnect duplicated questions. Duplicating a Clio Grow intake question copies everything except the custom field connection. Reconnect the duplicate manually, or the mapping silently breaks.

Renaming fields after templates depend on them. A practitioner post from Streamlined Legal on LinkedIn warned that changing a custom field name in Clio Manage can change its field code, which breaks document automation templates that rely on that code. Do not casually rename fields once they power templates, automations, or integrations.

Ignoring duplicate contacts from public forms. Practitioners on Reddit report that public Clio Grow intake forms embedded on a website can create duplicate contacts, requiring cleanup workflows.

Wrong contact vs matter choice. Putting “Accident Date” on the contact instead of the matter means that date travels with the person to every future matter. Put case facts on matters and person facts on contacts.

Treating API mapping like form mapping. API integrations that write directly to Clio custom field values need to distinguish field definitions from field value instances. A Stack Overflow discussion on Clio API updates shows that using the wrong ID can trigger errors or create duplicate entries.

If your firm uses a complete intake solution that spans phone, chat, and web forms, these mapping mistakes multiply across every channel.

How to Test Your Clio Field Map

Every field map should be tested before going live. Run through this checklist.

Before Building

• List the downstream uses for each field: conflicts, routing, reporting, documents, follow-up, deadlines
• Decide whether each answer belongs to the contact, matter, related contact, note, or document
• Prefer structured field types for data the firm will filter, sort, automate, or merge
• Skip fields that have no owner, no purpose, and no downstream use
• Document the field name, object, type, allowed values, intake question, and downstream use

During Setup

• Create required Clio Manage fields first if Manage or Draft is the system of record
• Sync Manage fields to Grow before building intake questions
• Match question type to field type using the compatibility table above
• For dropdowns, define the canonical choices in the custom field, not in the question
• Do not expect paragraph text, multi-select, section breaks, or file attachments to map
• Reconnect mappings after duplicating any intake questions

After Setup

• Submit a fake intake form and confirm answers appear in the correct contact or matter custom fields
• Confirm dropdown answers preserve the exact expected values
• Confirm document templates still generate correctly with the mapped data
• Confirm staff can search, filter, and report using the fields
• Confirm public forms or external tools do not create duplicate contacts
• If using APIs or AI intake, confirm updates do not create duplicate custom field values
• Document the entire field map so future staff do not rename, delete, or duplicate fields blindly

Where AI Intake Tools Fit

AI intake tools and virtual receptionists can collect information from calls, chats, SMS, and web forms 24/7. But the value of that collection depends entirely on whether captured answers land in the right structured Clio fields.

A transcript is useful for review. A mapped field is useful for routing, reporting, follow-up, deadlines, and document automation. The difference is the field map.

Here is how mapping works with AI-collected answers for a personal injury firm:

• AI asks: “When did the accident happen?”
• Field map sends the answer to: Clio matter custom field “Accident Date” (date type)
• AI asks: “Do you already have a police report?”
• Field map sends the answer to: Clio matter custom field “Police Report Available” (checkbox)
• AI asks: “Tell me what happened.”
• System stores the narrative as a note or transcript, not a structured field

AI makes Clio intake field mapping more important, not less. When an AI virtual receptionist captures answers around the clock, the firm needs a clean map so those answers do not become unstructured transcripts that staff must retype the next morning.

Third-Party Integration Notes

The mapping concept extends beyond Clio Grow. Lawmatics’ Clio Manage integration, for example, maps fields at both the contact and matter levels but requires compatible field types. Any external intake platform pushing data into Clio faces the same compatibility rules.

For direct API integrations, the implementation must update existing Clio records rather than blindly adding new field values. Practitioners on Reddit who have built automated intake pipelines on the Clio API report that they had to query matters first, retrieve existing custom field value IDs, and map extracted data to those IDs before patching. Otherwise, duplicate field entries appeared.

Frequently Asked Questions

Why isn’t my Clio custom field showing as a mapping option?

The most common reason is a field-type mismatch. Clio only shows custom fields whose type matches the intake question type. Also, paragraph text, multi-select, section breaks, and file attachment questions cannot be mapped at all. Other causes include fields created in Manage but not synced to Grow, field types that do not sync (Contact Select, Matter Select, Integer, Time), and non-admin user permissions.

Can paragraph text or file uploads map to Clio custom fields?

No. Clio explicitly excludes both from custom-field mapping in the Grow intake form builder. Paragraph answers should stay as notes or form PDFs. File uploads should be stored as documents.

Should referral source be a contact field or matter field?

It depends on how the firm reports on it. If referral source describes how the person found the firm generally, a contact field works. If it tracks the source for a specific inquiry or marketing campaign, a matter field is better. Place the field wherever the firm will report on it and reuse it.

Do Clio Grow and Clio Manage custom field values sync both ways?

Not automatically. Clio states that values edited in Manage do not sync back to Grow. To keep data consistent, make changes in Clio Grow and then update Manage. This one-way sync behavior is a common source of confusion.

How many custom fields should a law firm create?

There is no universal number. The governing rule is that every mapped field should have a job: routing, filtering, conflict checks, document automation, reporting, or follow-up. If the field will not be used for any of these, the information may belong in notes or a narrative section. Practitioners on Reddit consistently recommend starting lean and adding fields only when a downstream use justifies them.

Can an AI receptionist fill Clio custom fields?

Yes, if the AI system is configured around the firm’s field map. An AI receptionist can collect answers during calls, chats, or SMS conversations and push structured data into Clio contact or matter custom fields through an integration. The key is ensuring the AI’s outputs match the field types and values Clio expects, and that the integration updates existing records rather than creating duplicates.

What is the difference between a custom field and a custom field set?

A custom field is a single data slot (like “Accident Date” or “Injury Type”). A custom field set is a grouped collection of related fields, often organized by practice area. For example, a “Personal Injury” field set might contain fields for accident date, injury type, police report status, and insurance claim number.

Does mapping replace the full intake form?

No. Mapping creates structured data in specific Clio fields, but some intake answers will still live as narrative responses, PDFs, notes, or uploaded files. The full intake form remains useful as the complete record of what the prospect submitted. Mapping is for reusable, structured data. The form is the full picture.

---

If your firm is ready to connect intake answers to Clio custom fields automatically, whether from phone calls, web forms, or chat, book a demo to see how an AI-powered intake workflow maps caller answers into structured Clio data from day one.