CRM fields traditionally contain facts entered by people, synchronized from another system, or calculated with deterministic logic. Many valuable business judgments do not fit those paths. A team may want a concise company-positioning summary, a normalized use-case category, a reason a deal appears risky, or a description assembled from several related facts. These outputs require interpretation, yet they still need the structure and operating discipline of ordinary CRM data.
AI fields bridge that gap. An administrator defines a prompt, references only the CRM values needed with double-brace variables, chooses a return type and model, and decides when the field may run. At execution time the system loads the referenced values, substitutes them into the prompt, asks the AI-field agent for a bounded result, validates that result against the configured type, and stores the accepted value on the record. Users can then see it in grids and record pages instead of searching through a separate chat transcript.
That design creates both power and responsibility. A generated field can become a filter, a list criterion, a workflow input, or a fact that shapes a customer conversation. It therefore needs clearer evidence rules than an informal assistant answer. This guide explains the operating model, the differences from nearby CRM features, the questions to answer before creating a field, and the controls that keep generated data useful over time.
Choose the right kind of CRM field or workflow
AI fields are one tool among several. Start with the most deterministic mechanism that can produce the required outcome, then add interpretation only when the business question genuinely needs it.
| Mechanism | Best for | How it changes | Primary risk |
|---|---|---|---|
| Standard field | Verified facts entered or synchronized from a trusted source | A person or integration writes a new value | Missing ownership or inconsistent entry |
| Formula field | Exact arithmetic, dates, conditions, and transformations | Recalculates deterministically from dependencies | A formula that hides unclear business definitions |
| AI field | Classification, summarization, extraction, and bounded research | Runs under selected manual or automatic policies | Unsupported inference becoming accepted as fact |
| Enrichment | Provider-supplied identity, firmographic, or contact facts | Refreshes through an external data provider | Stale, mismatched, or weakly sourced data |
| Workflow or assistant | Multi-step action or an interactive question | Runs after an event or a user conversation | Too much authority or context for the task |
Understand the full AI-field execution path
A reliable AI field starts before a model receives anything. The field definition identifies its object, prompt template, referenced dependencies, return type, model, and execution policies. When a record becomes eligible, the CRM loads only the referenced values from its database. It resolves formula dependencies and supported related-record references, renders those values into the prompt, and sends the rendered task to the AI-field service. The agent does not receive open-ended database access and does not independently browse through customer records.
The returned value is not written blindly. It must match the configured output contract: a number must parse as a number, a date must be a valid date, and a select result must match an allowed option. The run can also finish with no value when the available evidence cannot support an answer. Accepted output is stored on the record, while compact run state communicates whether work is queued, generating, complete, empty, or failed. This separation makes execution observable without treating fluent text as automatically valid data.
Treat typed output as part of the prompt contract
Return type determines what the field can safely do later. Text and multiline text work for concise descriptions and summaries. Number and INR currency support quantities that can be validated numerically. Yes or No works for a narrowly defined condition, while date and date-time require a source-supported temporal value. Select and multi-select are especially useful for controlled classification because the administrator defines the permitted labels in advance. A narrow type reduces ambiguity and makes filtering more dependable.
Type does not make an unsupported answer true. A perfectly formatted date can still be invented, and a permitted select label can still be chosen from insufficient evidence. The prompt should therefore define both the output form and the evidence threshold. It should say what to return when the source is absent, contradictory, or stale. For consequential information, use a separate reason or evidence field rather than forcing one compact label to carry confidence, provenance, and business meaning at the same time.
Reference the smallest useful set of CRM values
Inline variables such as {{account.website}} or {{deal.requirements}} make dependencies explicit. Before execution, the CRM replaces those references with current values. This is more controlled than sending an entire record because administrators can see which context the field depends on, the system can detect when a relevant dependency changes, and unrelated personal or commercial data does not enter the request. The prompt template remains understandable even when the underlying values vary by record.
More context is not automatically better. An account summary built from every available note can blend different periods, stakeholders, and certainty levels. Begin with fields whose meaning, ownership, and freshness are known. Distinguish an observed customer statement from an internal assessment and a formula-derived value. If one AI field references another, document the chain so users understand that the final result includes generated evidence rather than only verified inputs. Short dependency paths are easier to test, refresh, and explain.
Separate CRM evidence from public-web research
Some fields can be answered entirely from CRM context: a concise renewal brief, a normalized category from an internal requirement, or a next-step quality assessment. Others genuinely require current public information, such as summarizing how a company describes its product on its own website. The prompt must explicitly request public research when it is required. The AI-field agent can then use bounded Tavily Search or Crawl requests and may return the exact public source URLs that materially support the result.
Public research is not permission to infer private facts or collect everything discoverable about a person. Use an authoritative website when the task concerns the company’s published claims, and use a broader search only when the question needs it. The tool respects request and content limits, so a crawl is not a guarantee that every page was retrieved. Each web-agent request consumes one shared credit in addition to the model-rated credits for the AI run. Research should therefore be deliberate, relevant, and visible in the field’s operating cost.
Choose a model according to task difficulty and volume
Intelligent CRM offers GPT-5.4 Mini and GPT-6.1 Sol during AI-field creation. GPT-5.4 Mini is the cost-efficient choice for high-volume work such as straightforward normalization, short extraction, or classification with strong examples. GPT-6.1 Sol is intended for more complex work where the prompt asks the model to reconcile several inputs or produce a nuanced bounded summary. The stronger model is not a substitute for a clear prompt, clean dependencies, or an output type.
Evaluate the model with representative records before enabling broad automation. Include sparse records, long values, contradictory evidence, unusual but valid examples, and records that should produce no value. Compare correctness, abstention, stability, and credit use rather than judging a few polished sentences. A lower-cost model that reliably satisfies a narrow contract is often the better production choice. A complex field that remains unreliable with both models may need a different data design rather than another prompt revision.
AI fields are available with Intelligent CRM Pro. Model input and output use the shared team AI allowance at the selected model’s rate, and each outbound web-agent request adds one credit. Settings → AI usage shows total, remaining, input, output, and web-research credits, plus the team-member breakdown. Review this shared budget before turning a successful manual field into high-volume automation.
Match execution policy to freshness needs
AI fields can use more than one execution policy. Manual execution gives a user a Generate or Regenerate action on a grid or record page. Periodic execution refreshes values hourly, daily, or weekly. When value is empty queues eligible records that do not yet have a stored value, including initial population when that policy is enabled. When dependent fields change refreshes an AI field after a referenced input changes. The policies describe eligibility; the background worker performs the actual run and persists its result.
Choose the slowest policy that still keeps the field useful. A stable account description may need manual or weekly refresh, while a deal-risk explanation tied to current next steps may benefit from dependency changes. Automatic execution should not fire because an unrelated phone number changed. Current field definitions and dependencies determine impact at dispatch time, so removing a reference or disabling a policy stops later changes from selecting that field. This avoids a permanent hidden subscription to an obsolete prompt.
Design for no result, failure, and correction
A professional AI field is allowed to decline. Missing inputs, inaccessible research, conflicting evidence, or an output that cannot be validated should result in no value or a visible failure rather than a plausible guess. The grid and detail page distinguish Not generated, No result, Couldn’t generate, queued, and generating states. Manual fields offer Generate, Regenerate, Try again, or Retry as appropriate, while automatic-only fields do not pretend a manual action is available.
Correction should begin with the source and prompt. If a dependent field is wrong, fix that record value and rerun. If the result consistently overreaches, narrow the evidence contract or add an explicit no-result rule. If a classification is too broad, improve the allowed options. Generated changes are stored on the entity and can appear in its activity history, which helps a team see that the value changed. Do not edit around a flawed generator repeatedly; repair the definition that will affect future records.
Turn a website and CRM category into a reviewable account summary
A revenue-operations team wants a one-sentence positioning field for Accounts. It creates a text AI field that references {{account.website}}, {{account.industry}}, and {{account.description}}. The prompt instructs the agent to use the CRM description when it is specific, explicitly research the public company website when a URL exists, state only what the company publicly offers, avoid guessing customer size or traction, and return no value when neither source supports a description. The team selects GPT-5.4 Mini, enables manual and weekly execution, and tests records with valid sites, redirects, sparse descriptions, and companies with similar names.
The stored summaries appear beside Accounts in grids and detail pages, and users can regenerate an individual value after correcting the website. Website research consumes one shared credit for each Tavily request, while the model call uses its rated credits. When the agent cannot access reliable evidence, the field shows No result instead of inventing a market position. Operations reviews corrections monthly and keeps the original industry field separate so a generated sentence never silently replaces a verified classification.AI-field design checklist
- State the business question and how the stored value will be used
- Confirm that interpretation is needed and a formula or standard field is insufficient
- Choose the narrowest return type and allowed options that fit the outcome
- Reference only necessary CRM values with explicit double-brace variables
- Define what counts as sufficient, conflicting, stale, or missing evidence
- Tell the agent to return no value rather than assume an unsupported fact
- Request public-web research explicitly only when the task genuinely needs it
- Select the model using representative accuracy, stability, and credit tests
- Choose manual and automatic policies according to real freshness needs
- Test empty, contradictory, unusual, long, and intentionally unanswerable records
- Document ownership, dependencies, expected refresh, and prohibited downstream actions
- Monitor failures, no results, corrections, credits, and actual field usage
- Review or disable automation before materially changing the field definition
- Retire fields that no longer support an active business decision
Useful AI fields are designed, not merely generated
AI fields make interpretive work reusable by placing a typed, stored result where teams already manage Accounts, Contacts, Deals, and custom objects. Their advantage over an isolated assistant answer is operational: selected context is rendered into a defined task, output is validated, refresh is controlled, status is visible, and the result can participate in ordinary CRM views and history. That structure turns a prompt into a small data product.
The discipline matters more than the novelty. Prefer formulas for deterministic truth, enrichment for provider facts, and workflows for multi-step action. Use an AI field when a bounded interpretation deserves a durable place on the record. Keep its evidence narrow, allow no result, measure its cost and correction rate, and assign someone to maintain its meaning. The result will be less magical and far more useful.