Skip to content

Understanding Playbooks

Playbooks are a way to communicate with BaseRock AI via English prompts. These playbook prompt areas are available at various stages and for different uses. Let’s understand the hierarchy of playbooks and how to use them.

Precedence level (high to low): Test Case Level Playbook > Endpoint Level Playbook > Service Level Playbook

Coverage level (high to low): Service Level Playbook > Endpoint Level Playbook > Test Case Level Playbook

Playbook hierarchy

1. Service Level Playbook:

Service-level playbooks have the highest coverage—they apply to the entire service. Any data or instruction that needs to be reused across multiple endpoints or test cases can be defined here; it then automatically cascades, thereby reducing repetition.

2. Endpoint Level Playbook:

These playbooks take precedence over the service level. If there are instructions that need to override the service level but apply to all test cases of that endpoint, they can be added here.

For example:

In the service playbook, let’s say you define a variable in the “Context Variables” section as: user_name: johndoe123 The service-level playbook can then refer to it as ${user_name} for some instruction. However, if there is an endpoint /login that specifies: POST /login with user_name: johnwick321 then the endpoint-level value of user_name i.e johnwick321 will override the service-level value i.e johndoe123.

Additionally, if the username (or any variable) is dynamically generated (ex: random email address) at runtime within the endpoint definition, that generated value will also take precedence over the service-level variable.

There can be multiple playbooks created within an endpoint for different flows like default user flow, negative user flow, edge case user flow, etc. as shown in the scree below:

Endpoint playbooks

3. Test Case Level:

When there are specific test-case-level validations that depend on the domain, these can be achieved by selecting the existing playbook from the dropdown and associate the respective test case with a given flow (as per the playbook).

Any additional validations can also be mentioned in the "Validation steps" prompt area below.

Test case level playbook

Reliability & Human-in-the-Loop (HITL)

A common concern with English-based prompts is the risk of misinterpretation. BaseRock eliminates this uncertainty by maintaining Human-in-the-Loop (HITL) control through AI Workflow Steps.

Transparent Action Mapping

Before execution, BaseRock translates your natural language instructions into a technical blueprint. This allows you to verify exactly what the AI intends to do:

  • API Specifications: View the exact URL, headers, and payload.
  • Variable Management: Track which values are being referenced or saved from responses.
  • Validation Rules: Confirm specific status codes or body schemas required for success.

Full Editability

You retain final authority. If a step requires adjustment, you can refine your English prompt in the Playbook or manually edit the payload, headers, and logic directly in the workflow UI.

AI workflow steps (HITL)

Note

It's always recommended to edit the playbook in english rather than making changes directly to AI workflow steps so the english steps and workflow steps are in sync.

Check section: Playbook Usage to understand the best practices and some examples.