Guide

Designing a Runbook with Triggers and Actions

2 min read

Get the document

Tell us where to send it. The PDF lands in your inbox in under a minute.

About

About this guide

Build a no-code, event-triggered response playbook on the visual canvas, then govern it with retry, throttle, and a circuit breaker.

This guide shows how to design one runbook end to end in PMAP, from a trigger event and condition tree to an ordered action list, without writing code. You learn how the event bus and durable workflow engine fit together, how to constrain a trigger with an AND/OR condition tree, and how to wire template variables across actions.

Designing a Runbook with Triggers and Actions
The Runbooks workspace: a KPI strip, a filterable definitions grid, and an inline active toggle on every row.

It is written for security engineers who want repeatable, governed response. By the end you can pick the right trigger from 16 event types or a cron schedule, compose actions from the 22-action catalog with per-action retry and conditional branching, read the runbook back on the ReactFlow canvas, dry-run it against a real past payload with no side effects, and operate it safely under throttle, concurrency gating, and a 10-failure circuit breaker.

Inside this guide

  • See how the event bus and durable workflow engine drive automation.
  • Start the wizard, set the basic identity, and pick a trigger from the 16 event types.
  • Constrain the trigger with an AND/OR condition tree over dot-path fields.
  • Compose actions from the 22-action catalog and wire template variables with per-action retry.
  • Add flow control with when, sleep, and await_signal, or schedule a cron trigger.
  • Read the ReactFlow canvas, then dry-run with no side effects before activating.
  • Govern live runs with throttle, concurrency gating, and the circuit breaker.

Before you start

  • A PMAP account with runbook read and create permissions in your working company scope.
  • Familiarity with the platform events your automation should respond to, such as finding created, SLA breached, or scan finished.
  • Any external delivery targets your actions need: SMTP for email, a Slack or Teams incoming webhook, or an ITSM integration.
  • A clear idea of the AND/OR conditions that should gate the runbook, expressed against fields like finding.severity or asset.criticality.
  • For durable sleep or await-signal steps, a tenant where PMAP_RUNBOOK_ENGINE is set to workflow, since the default inline engine skips those action types.

See it live

Ready to see PMAP in action?

Talk to our team or jump straight into a guided tour of the platform.

We use your email only to set up your guided tour. No marketing drip, no third-party tracking.