Choosing when an AI field runs is an operating-policy decision, not a convenience setting. A field that describes a company website may tolerate a weekly refresh. A field that classifies a newly created support request may need a value as soon as the record is empty. A deal-risk explanation may need to respond when a referenced next step or close date changes. A sensitive judgment may deserve a deliberate manual run instead of background execution.
Intelligent CRM supports four execution policies for AI fields: manual, periodic, when the value is empty, and when referenced dependencies change. A field can use more than one policy. That flexibility matters because creation, maintenance, correction, and investigation are different events. One trigger rarely handles every part of a field lifecycle well.
The platform still applies one consistent execution path. It loads the referenced CRM values, substitutes those values into the prompt, sends the rendered prompt to the selected AI-field agent, validates the typed result, and stores the accepted value on the record. The trigger decides when that path begins; it does not grant the agent broader database access or permission to invent missing context.
Choose a trigger by the event that makes the value useful
Each policy solves a different freshness problem. Multiple policies can be combined when their responsibilities are clear.
| Execution policy | Best fit | Main strength | Primary risk |
|---|---|---|---|
| Manual | Research or judgment initiated by a user | Maximum intent and review control | Values may remain missing or stale |
| Periodic | Public or internal facts that age over time | Predictable refresh cadence | Unnecessary runs when evidence is unchanged |
| When empty | New or incomplete records that need an initial value | Fills gaps without replacing existing results | A poor first result can look complete |
| Dependencies changed | Derived values tied to referenced CRM inputs | Refresh follows relevant record changes | Noisy dependencies can cause excessive work |
Define the freshness contract before selecting a trigger
Start by naming the decision that consumes the field and how old the value may be before it becomes misleading. A company-positioning summary used for quarterly account planning has a different freshness requirement from a request classification used for today’s queue. Write the acceptable delay, the source fields that can invalidate the result, and whether an old value should remain visible while a replacement is generated. Without that contract, teams often select every trigger and create expensive activity without improving a decision.
Also define what a refresh means. Some fields should replace the previous value whenever evidence changes. Others should preserve the existing value until a person asks for new research. A field based on a stable contract date may need dependency-based refresh, while a public-web description may need periodic research. The trigger should correspond to a recognizable business event rather than a vague desire to keep everything “live.”
Use manual execution for deliberate research and review
Manual execution is appropriate when a user should decide that the available context is ready, the task has meaningful cost, or the answer needs human attention immediately afterward. When manual execution is enabled, a user can generate an empty value and regenerate an existing value from the grid or record page. The stored value remains visible while a replacement is queued or running, so a refresh does not unnecessarily erase useful context.
Manual should not become an excuse for hidden administrative work. If every newly created record requires the same safe classification, an empty-value trigger may be more consistent. Reserve manual execution for tasks such as an account research brief before a meeting, a complex deal review, or an exception analysis in which timing and intent matter. The action should use a clear prompt, bounded inputs, and a typed result even though a person initiated it.
Use periodic execution when age—not a specific edit—is the signal
Periodic execution supports hourly, daily, and weekly cadences. It fits values whose evidence can change outside the CRM or whose freshness cannot be inferred from one record update. Examples include a public website positioning summary, a periodically reviewed market category, or a customer-health narrative that should be refreshed on a known operational rhythm. Choose the slowest cadence that still supports the decision.
A schedule is not evidence that something changed. An hourly refresh of a stable company description spends credits and creates operational noise without producing new value. Estimate eligible record count, runs per period, model choice, and likely web-agent requests before enabling a cadence broadly. Remove the periodic policy when scheduled refreshes should pause; future scheduler checks use the current field definition rather than a permanent subscription created when the option was first selected.
Use the empty-value policy for initial population
The empty-value policy looks only at the AI field’s own stored value. It does not perform a broad dependency analysis. When an eligible record has no result, the system can queue a run to populate it. This is useful for a new record, a newly added AI field, or a field whose value was intentionally cleared. Enabling the policy can also schedule initial population for existing records that are empty, which makes rollout behavior important.
Empty does not mean that the inputs are sufficient. A reliable prompt must permit no result when required evidence is missing. Otherwise the model may turn incomplete context into a plausible-looking value that prevents another empty-field attempt. Define required references, allow the agent to return no value with a reason, and monitor the no-result state. Do not convert “unknown” into a default category merely to make every cell appear complete.
Use dependency refresh only for referenced evidence
The dependency-change policy connects refresh to the CRM fields referenced in the prompt. The backend resolves the current AI-field definition, determines whether the policy is enabled, and checks whether a relevant dependency changed. It is not a permanent listener embedded in the source field. If the prompt is edited and a reference is removed, a later change to that removed field should no longer select the AI field for refresh.
Keep the dependency set small and meaningful. Referencing an account name, website, industry, and customer-stated requirement may make sense for a positioning field. Referencing a frequently updated activity counter may create a refresh after every minor interaction. Formula references can introduce underlying dependencies, and related-record context can broaden the records affected by a change. Review the dependency graph as an operational design, not only as prompt syntax.
Combine policies by assigning each one a distinct job
Multiple policies are valuable when they cover different lifecycle stages. A field can run when empty to create its first value, refresh when referenced evidence changes, and still allow manual regeneration when a user wants an immediate review. A periodic policy might be added only when part of the evidence comes from the public web and no CRM change can signal that the external fact changed.
Avoid combinations that merely duplicate work. If dependency changes already capture every meaningful input, a daily schedule may add cost without improving freshness. If a field is intentionally reviewed by a manager, automatic empty population may bypass that checkpoint. Document why each selected policy exists, which event it covers, and which policy should be removed if the operating process changes.
Design queueing, retries, and stale-write protection
AI-field runs are asynchronous. A trigger queues work, the worker loads context, the agent produces a typed outcome, and the result is persisted. The record carries compact run state such as queued, running, succeeded, no result, or failed so grids and detail pages can communicate progress. An active claim prevents the same field and record from being treated as unlimited parallel work merely because several events arrive close together.
A retry must not let an old result overwrite a newer context. The implementation versions field definitions and fingerprints rendered input so persistence can reject stale work. Successful model output can be staged before final record persistence, allowing infrastructure retries to finish the write without repeating the model call. Operators should still test rapid edits, repeated delivery, worker interruption, prompt changes, and deletion so the expected result wins safely.
Budget model work and web research separately
Every AI-field run uses the selected model and contributes model-rated input and output credits to the shared team allowance. GPT-5.4 Mini is intended for cost-efficient high-volume work, while GPT-6.1 Sol is available for more complex work. The stronger model should be selected because the task needs it, not because automation made the individual run less visible.
Public-web research is an additional decision. When the prompt explicitly requires current external research, the agent may make bounded Tavily Search or Crawl requests. Each outbound web-agent request consumes one shared credit in addition to model-rated credits. A periodic field that performs website research across thousands of records therefore has a different cost profile from a dependency-based classification using only substituted CRM values.
Monitor outcomes instead of counting runs
Run counts reveal load but not value. Track the share of runs that produce a valid result, return no value, fail, or replace an existing value. Sample generated values against their referenced evidence. Measure how often users regenerate, correct a source field, or stop using the output. A high regeneration rate may indicate stale cadence, weak prompts, missing dependencies, or an unsuitable task.
Record activity should show accepted AI-field value changes so users can understand when the record changed. Run records and source metadata help diagnose model, web, and persistence outcomes without storing rendered prompts that may contain customer data. Combine these technical signals with business measures such as faster qualification, better queue consistency, or reduced manual research. Automation is justified when it improves the work, not when it maximizes the number of populated fields.
Use three policies for three different freshness events
A revenue-operations team creates a multiline Account field that summarizes public positioning using the account website and current CRM industry. The prompt explicitly asks for website research, forbids assumptions, and permits no result when the site cannot be verified. The team enables when-empty so existing unpopulated accounts can receive an initial value, dependency-change so a corrected website or industry can refresh the result, and manual so an account owner can regenerate before a strategic review. It does not enable hourly or daily execution because most company positioning changes slowly.
The rollout begins with manual runs on a small account cohort and GPT-5.4 Mini. Operations measures successful values, no-result reasons, web-agent requests, and owner corrections before enabling automation. It later adds a weekly cadence after confirming that the full account population and expected research cost are acceptable. Each Tavily request remains visible in web-research credit usage, while record activity shows accepted changes. The field stays fresh enough for planning without turning every account into constant background work.AI-field execution-policy checklist
- Name the business decision that consumes the generated value
- Define how old the result may be before it becomes misleading
- List the exact referenced fields that can invalidate the result
- Use manual execution when timing or review should remain deliberate
- Use the slowest periodic cadence that meets the freshness requirement
- Use when-empty for population without treating missing evidence as certainty
- Allow a no-result outcome when required inputs are insufficient
- Use dependency refresh only for fields that materially affect the answer
- Document why each policy is selected when policies are combined
- Estimate record volume, model credits, and possible web-agent requests
- Test repeated triggers, concurrent edits, worker interruption, and retries
- Confirm old work cannot overwrite a newer prompt or record context
- Pause scheduled work by removing the periodic policy from the definition
- Review failure, no-result, regeneration, correction, and replacement rates
- Keep accepted value changes visible in record activity and operational review
Refresh policy is part of field meaning
An AI field is not fully defined by its name, prompt, and return type. Its execution policy explains when the organization considers the result worth creating or replacing. Manual runs express user intent; schedules address age; empty-value runs address missing outputs; dependency refresh addresses changed evidence. Combining them is useful only when each policy owns a distinct event.
Intelligent CRM provides these controls across Accounts, Contacts, Deals, and custom objects, but the team still owns the freshness contract and cost. Start with a narrow cohort, permit uncertainty, measure outcomes, and expand only after the trigger produces useful changes at a sustainable rate. The best automation is quiet: it runs for a reason, preserves the last useful state while working, and makes failures understandable.