Building Your First IT Playbook
Overview
Playbooks are automated workflows that execute multi-step processes by pulling data from connected systems and taking actions. They control what information is collected, who needs to review a request, and what happens after a decision is made. This guide walks through how to build your first IT Playbook using a password reset request as an example.
The goal of this example is to demonstrate Playbook structure and flow, not to prescribe a specific technical implementation.
Step 1: Define the request type
Start by identifying the type of request your Playbook will handle. In this example, the request type is a password reset request.
When an employee submits this request through Slack or Microsoft Teams, Console captures it as a structured Request that the Playbook can act on. This establishes what the request is for, and when the Playbook should be triggered.
Step 2: Collect required information during intake
Next, configure intake questions to gather the information needed to handle the request. Intake questions are presented to the employee as part of the request flow.
For a password reset request, this might include:
Which account needs to be reset
Whether the issue is blocking work
Any additional context required for review
Collecting this information upfront helps determine how the request should be handled and reduces follow-up questions.
Step 3: Add approval steps (if needed)
Depending on your policies, password reset requests may require approval. Playbooks can include approval steps that pause the workflow until a human reviews the request.
Approvals allow teams to:
Review request details before proceeding
Enforce internal policies consistently
Decide whether the request should move forward
Approval logic is defined directly in the Playbook and applied automatically to matching requests.
Step 4: Route or take action on the request
Once intake and approvals are complete, the Playbook determines what happens next. This may include:
Routing the request to an IT operator for manual handling
Triggering an action through a configured integration, where supported
Escalating the request based on responses or conditions
The exact behavior depends on how your integrations and actions are configured.
Step 5: Track the request through completion
Throughout the process, the request remains visible in Console. Operators can view request details, respond to questions, and track progress from submission through resolution.
Once the request is resolved, it is marked complete and remains available for reference. This provides a record of how the request was handled and supports consistency over time.