Problem
A conversational agent can make a CRM update feel like one step even when the action depends on several hidden decisions: which record is the target, which source is authoritative, whether the state changed during review, who is allowed to approve, and whether the destination committed the write exactly once.
Why it matters
Outreach's September 2026 confirmation release makes the approval surface visible. RevOps can use the same pattern regardless of vendor: separate proposal from execution, show the reviewer enough state to make a decision, and verify the destination after the write.
1. Define consequential fields
List the CRM objects and properties an agent may propose changing. Separate low-impact internal metadata from owner, stage, forecast, amount, close date, consent, customer communication, billing or entitlement fields. Give each field an authority source and action owner.
Do not grant write access because a model can read the field. Read, recommend, approve and execute are separate permissions. Start with the smallest object and field set required for one named workflow.
2. Build a decision-complete preview
Show the stable target ID, display name, association context, current field values, proposed values, source evidence, reason, executing identity and any downstream workflow consequence. Highlight unknown or conflicting state rather than collapsing it into a guess.
The reviewer should be able to approve or reject without opening another tab for basic context. If the decision requires an external contract, billing record or customer message, link that evidence directly from the preview.
3. Re-check state after approval
Capture a version or updated-at marker for the reviewed fields. Immediately before execution, compare the destination with the approved state. If a material value changed, invalidate the approval and present the new state instead of merging silently.
Use stricter changed-state rules for commercial, ownership, consent and customer-facing actions. A stale approval is a new decision, not the same approval delayed.
4. Execute once and verify
Assign a stable execution or business-action ID. Where the destination supports idempotency, use it; otherwise query for the intended business effect before retrying after a timeout. Record the destination response and resulting record version.
Read the record back after the write and compare it with the approved state. Validation rules, permissions or downstream automation can change the final result even when the request returned success.
5. Route exceptions to an owner
Classify denials and failures: wrong identity, missing evidence, changed state, policy violation, permission denial, duplicate action, destination failure or human judgment. Give each class a named owner and resolution path.
Review the queue as operating telemetry. Repeated identity failures are a data problem; repeated policy denials are an action-contract problem; repeated retries suggest an integration-control problem.
6. Expand authority only after a clean cycle
Run the gate on a small cohort with normal and adversarial cases: duplicate accounts, multiple opportunities, recently changed owner, missing required field, concurrent workflow update, timeout and retry. Sample both approved and denied actions.
Expand one dimension at a time: more records, another field, another object or a less reversible action. Keep an emergency stop path and preserve enough evidence to reconcile every write made before shutdown.
Step-by-step workflow
- Choose one agent job and list exactly which CRM fields it may propose.
- Name the authoritative source and action owner for each consequential field.
- Create a preview that shows target ID, current values, proposed values and evidence.
- Test ambiguous identity and missing required fields; require an explicit exception.
- Approve a test action and change the source record before execution to prove state is rechecked.
- Retry the same action to prove duplicate prevention or idempotency.
- Verify the destination record after execution and record the resulting version.
- Test permission denial, validation failure, timeout and cancellation around the write boundary.
- Route each exception class to a named owner with a due date.
- Review one full operating cycle before widening the object, field or record scope.
CRM fields and signals needed
- CRM object, stable record ID, associations and updated-at/version marker
- Current and proposed values for every material field
- Source record IDs, evidence timestamps and authority owner
- Agent version, user identity, permission scope and approval timestamp
- Execution ID, destination result, post-write state and rollback status
Operating quality check
Use this check before adding more tooling. The goal is to prove that the workflow is owned, current, and inspectable inside the system of action.
| Area | Healthy pattern | Risk pattern |
|---|---|---|
| Identity | Stable object and record ID plus association context are visible | Reviewer sees only a display name or inferred account |
| State | Current and proposed values are both visible | Preview describes only the requested outcome |
| Evidence | Material claims link to current source records | Agent summary is treated as source evidence |
| Concurrency | Material state is rechecked immediately before write | Approval remains valid after record changes |
| Execution | Stable action ID and post-write verification exist | Retries can duplicate work or success is assumed |
Common mistakes
- Showing only the proposed value and hiding the current record state.
- Treating a user click as permission for any field the agent can reach.
- Executing an approval after the target record materially changed.
- Retrying a timed-out request without checking whether the first write committed.
- Keeping the only audit evidence in the conversation transcript.
- Measuring approval rate without inspecting denials, corrections and wrong-record near misses.
Example operating rhythm
- Before launch: test normal, duplicate, missing, changed-state and denied cases.
- Daily in the first production week: sample approved, rejected and failed writes.
- After any prompt, permission, schema, workflow or connector change: rerun the representative test set.
- Weekly: review exception reasons and duplicated or corrected actions.
- Monthly: remove unused write permissions and confirm rollback and emergency-stop ownership.
Tooling options
- Use the CRM record history as the durable evidence for final writes.
- Use source systems for facts they author instead of copying every value into an agent prompt.
- Use a separate approval record or structured execution log when the conversational surface cannot preserve the full decision packet.
- Use an exception queue for ambiguous identity, stale evidence, changed state and permission failures.
- Keep read and write identities separate where the platform allows it.
Source notes
These sources support the workflow model and product concepts. They do not prove a specific business outcome, benchmark result, or vendor claim.
- Outreach September 2026 release notes: Official release notes describing Omni confirmation, cancellation, Slack and related September changes.
Last updated: 2026-09-20
Decision frameworks to read next
FAQ
Does every CRM write need manual approval?
No. Low-impact deterministic writes can be policy-approved when identity, prerequisites, permission, idempotency and rollback are well defined. Higher-impact or ambiguous changes deserve explicit review.
What should invalidate an approval?
A change to material state, target identity, evidence, permission or policy between preview and execution should invalidate the original approval.
Why verify after the write?
The destination can reject, transform or immediately overwrite a request. Post-write verification proves the final business state rather than only the intent.
What is the safest first agent write?
A reversible internal action on a controlled record set, such as a tagged task or test property, before commercial or customer-facing authority is added.