Why checkpoints exist
In GTM workflows, reads are often cheap and safe, but writes can change CRM records, send messages, or update downstream systems. Checkpoints keep preview useful without pretending that risky writes should execute automatically.
How validation uses them
Validation checks the draft before preview. One of the runtime rules GTMship enforces is that every ctx.*.write(...) call must include a checkpoint. That prevents hidden writes from slipping into a draft unnoticed.
What a checkpoint should show
Target action
The operator should be able to see what system is about to change and what write operation is being attempted.
Object context
Good checkpoints make the target record, object type, or downstream resource clear enough to review without digging through raw code.
Payload summary
The intended write body should be inspectable so reviewers can spot bad field mappings, wrong values, or unexpected side effects.
Approval reason
There should be a clear explanation for why this write pauses, especially when the workflow mixes safe reads with high-impact mutations.
Preview states
success
The preview completed with no blocked writes or runtime errors.
needs_approval
The preview reached one or more write checkpoints and needs operator approval before those writes continue.
error
The preview failed because of a code, auth, or runtime problem that needs fixing before deployment.
Recorded operations
Preview captures what the workflow tried to read, write, and branch on so the draft can be refined with concrete feedback.
Common writes that pause in preview
- CRM mutations: creating leads, updating lifecycle stages, or overwriting owner fields.
- Outbound communications: sending messages, emails, or notifications to real people or channels.
- System-of-record changes: updating tickets, tasks, or internal records that other teams depend on.
- Any non-idempotent external write: if retrying the call blindly could be risky, GTMship treats it as something worth reviewing.
Typical operator flow
- Generate or revise the workflow draft.
- Run validation to catch missing checkpoints or unsupported patterns.
- Preview with sample input.
- Inspect the pending write and decide whether to approve or revise the draft.
- Only move forward to build or deploy after the write path is understood.
draft
-> validate
-> preview
-> needs_approval?
yes -> inspect + approve or revise
no -> continue to build/deploy