Human approval and preview patterns for CRM changes
How to put a useful human checkpoint in front of a durable GTM action, show the exact proposed change, and record approval without turning every workflow into a meeting.
On this page
Approval is a control only when the person can see what they are authorizing. “Approve AI update” gives them a button and withholds the decision.
Preview the diff
| Preview field | Example |
|---|---|
| Record | Priya Shah, Acme Manufacturing |
| Current value | account_status = prospect |
| Proposed value | account_status = customer |
| Evidence | Signed order, observed 2026-08-23 |
| Rule | customer-status-v2 |
| Consequence | Customer reporting population changes |
| Undo | Restore previous value with reason |
Render the old and new values side by side. Include fields that will change indirectly, such as owner, suppression, or queue state.
Match approval scope to risk
| Pattern | Good for | Control |
|---|---|---|
| Single-record approval | A high-consequence exception | Exact diff and named approver |
| Bounded batch | Repeated low-risk cleanup | Population, count, sample, and rollback |
| Queue review | Ambiguous recommendations | Reviewer chooses from allowed outcomes |
| Two-person approval | Sensitive or irreversible action | Separate requester and approver |
Do not make one approval step carry all four jobs. It slows safe work and still fails to describe the dangerous work.
Approval state machine
proposed → pending-approval → approved → applied
↘ rejected
↘ expiredRecord who changed state, when, and the reason. If the record changes after the preview, invalidate the approval and create a new preview. Applying an old approval to a new record state is a race condition.
Platform path
Salesforce approval processes and Flow can implement bounded approval paths; HubSpot workflows can create tasks or route records for review, with exact options depending on the account and object. The design remains portable: store the proposed diff and approval event in the system that owns the business field. Consult Salesforce approval documentation and HubSpot workflow documentation before choosing a native action.
Make the decision real
An approval step is useful only when the reviewer has authority, enough context, and a meaningful choice. Show the current value, proposed value, source, reason, downstream effect, and deadline together. Do not make the reviewer reconstruct the change across tabs or approve a label such as “update record” without seeing the fields.
For high-volume work, preview a representative batch before approving the population. Show counts by segment, unusual values, conflicts, and records excluded by controls. Approval should bind to the exact query, policy version, and proposed changes. If those inputs change, request approval again.
Preserve rejection, requested changes, expiry, and cancellation as first-class outcomes. Measure approval time, rejection reasons, edits after approval, and reversal rate. Frequent reviewer edits are evidence that the upstream decision or preview needs work, not proof that people are the bottleneck.
Related: Risk tiers and automation eligibility, Limits, kill switches, and staged rollout, and Decision ownership and override authority.
Related guides
FAQ
- What should a CRM change preview show?
- Show the record, current value, proposed value, source, reason, rule version, actor, and any downstream action. The approver should be able to reject the exact change, not a vague description of what a workflow might do.
- When should a workflow require human approval?
- Require approval when the action is external, difficult to undo, changes an authoritative field, affects consent or ownership, or crosses a risk boundary the business has set. Reversible internal work can often use sampling instead.
Get the next guide
New guides and the occasional note on GTM tooling. Don't worry, I won't drop you into a three-month nurture.