Updating a CRM

Task boundary

Updating a CRM is assessed as a specific task and workflow, not as a general endorsement of AI for the surrounding job. A narrow tool can preview and write selected reversible fields.

Assumptions

• Only status and next_contact_date may change in a preselected account queue.
• Every proposed write is previewed against the current record and explicitly approved.
• The CRM retains prior values long enough to test and perform rollback.

Decision

• Disposition: Proceed with controls
• Pattern: Tool workflow
• Inherent risk: medium

Rules that drive the decision

• Changing external state requires a bounded tool contract rather than a prompt-only pattern.
• Reversible, allow-listed writes may proceed with least privilege, preview, approval, and logging.

Why alternatives were rejected

• A prompt cannot perform the action.
• An unbounded agent has excessive permission.

Controls

• Restrict credentials to the queue, records, fields, and operation needed for this task.
• Reject stale-record versions, malformed dates, duplicate execution, and targets outside the allow-list.
• Log the proposal, approver, before-and-after values, result, and rollback status.

Acceptance threshold

These are example starting thresholds for a bounded pilot of this workflow, not universal benchmarks. For updating a CRM, the accountable owner should make them stricter when the task, consequence, or policy requires it.

• For 100 representative records, there are zero writes outside the queue or field allow-list and every write matches its approved preview.
• Rollback restores prior values in every forced-failure case; stop on the first permission-boundary or rollback failure.

Reassess when

• The workflow can create, delete, merge, message, or bulk-edit records.
• Approval becomes sampled, implicit, or detached from the exact proposed write.