Skip to main content
When a support agent needs to reproduce a scenario, verify a reported issue, or walk through a known workflow on behalf of a customer, Runbook mode gives them a structured way to do it. They don’t need to know how the journey was built — they just select the right case, choose an environment, and work through the steps.

​
When to use it

Use this flow when:
  • A support ticket references a known scenario and a matching Case exists.
  • You need to reproduce a specific customer situation against a real environment.
  • The outcome needs to be documented — not just observed.
  • You’re running a routine operational check that a journey already covers.

​
Key concepts

Cases as scenario presets. A Case is a saved set of values for a specific scenario — “Happy path,” “Expired token,” “Missing funding source,” and so on. Selecting a case in Runbook mode pre-fills all the run inputs and variables the journey needs. You don’t manually configure values; the case does it for you. Environment selection. Choosing the right Environment matters — sandbox, staging, and production have different data and behavior. Make sure you’re running against the environment that matches the scenario you’re investigating. Manual checkpoints. The journey author may have added manual checkpoints at steps where human confirmation is required. You’ll be prompted to mark what you observed before the run can continue. Evidence collection. Everything the runbook captures — responses, assertion results, your notes — becomes part of the evidence log for this run.

​
How it works

1

Find the right journey

Locate the journey that covers the workflow in question. If you’re working from a support case or ticket, it may already be linked.
2

Switch to Runbook mode

Select Runbook mode from the journey’s mode selector.
3

Select a case

Choose the Case that matches the scenario you’re investigating. The run inputs and variables are filled in automatically.
4

Select an environment

Pick the environment that matches the situation — usually the same environment the customer is on, or staging if you’re reproducing before escalating.
5

Run through the steps

Reqflo executes each step in sequence and presents the result. At each step, review the response and assertion outcomes. At manual checkpoints, mark your observations.
6

Report the result

When the run finishes, review the summary and share the report with your team or attach it to the ticket.

​
Examples

Reproducing a reported failure A customer reports their payout fails at the verification step. The support agent:
  1. Opens the Payout flow journey in Runbook mode.
  2. Selects the Verified account — low balance case.
  3. Selects the production environment.
  4. Steps through the journey — the verification step returns a 422 and the assertion on status fails.
  5. Notes the failure, copies the response body, and marks the checkpoint.
  6. The run summary shows the failed step, the assertion that failed, and the agent’s note. That goes into the ticket.
Routine operational check A support team runs a weekly runbook for a critical onboarding flow to confirm it’s behaving correctly in production. No case required here — the team uses default run inputs and marks each step as confirmed.