GTM workflow runbook template

A workflow specification tells builders what to create. A runbook tells operators what to do when the workflow is late, wrong, or quiet.

Copy this outline

Name and version:
Business outcome:
Accountable owner:
Operator:
Systems and source of truth:
Trigger and eligibility:
Current states:
Daily health checks:
Failure codes and retry policy:
Escalation owner and SLA:
Kill switch:
Rollback or replay procedure:
Weekly or monthly review:
Last verified:

Fill it from the real workflow. A generic incident page is not a runbook.

Daily checks

• new eligible items are entering the workflow;
• waiting items have an owner and due time;
• failed items have a reason and next owner;
• retries are below the documented cap;
• suppression counts match the policy events;
• no volume or spend limit is active unexpectedly; and
• the completion event is reaching the reporting system.

Record the check result. “Looks fine” cannot explain a silent failure three days later.

Incident path

1. Stop new risky actions if the failure can affect external records or messages.
2. Identify the last known good version and affected population.
3. Separate completed, in-flight, suppressed, and failed items.
4. Use the documented retry or rollback path.
5. Notify the owner with the scope, cause if known, and next checkpoint.
6. Record the correction and add a regression test before restarting.

Keep platform details current

Store links to the Salesforce Flow or HubSpot workflow, the version or configuration export, and the official documentation last checked. Platform screens and limits change. The runbook's business states and ownership should remain stable.

Write for the person holding the incident

A runbook should answer three questions quickly: what is affected, how do I stop further harm, and who decides what happens next? Put the current owner, backup, kill-switch location, dashboards, queues, and rollback procedure near the top. Architecture history can live elsewhere.

For each alert, document the meaning, first check, expected healthy range, and escalation threshold. Include saved queries or report links that identify the affected population. “Check the logs” is not a procedure unless the runbook names the log, filter, correlation ID, and result that distinguishes a retryable failure from a permanent one.

Exercise and maintain it

Run a tabletop review before launch and after material changes. Ask someone who did not build the workflow to diagnose a simulated timeout, bad credential, duplicate run, and incorrect population. Record what they could not find. Review ownership monthly and the full procedure quarterly, and update the runbook as part of every workflow release.

Related: Workflow states and job history, Retry, defer, and escalation, and GTM operating review template.