The Console Playbook Builder's Guide

Step 1: Create the Playbook

1. In the left sidebar, go to Train > Playbooks.
2. Click New Playbook. (If this is your first time, you may see a new playbook introduction modal; dismiss it to see the blank editor.)
3. Click the title field, which defaults to Untitled Playbook.
4. Rename it to Reset Okta Password.

You should now see the playbook editor with these main areas: Trigger, Instructions, Test, Publish Changes, Configure permissions, and Access.

Figure 2: The Playbooks list view. Click New Playbook (top right) to create a new playbook.

Figure 3: The blank playbook editor after clicking New Playbook. The title defaults to "Untitled Playbook" and a green toast confirms "Playbook draft created."

Step 2: Set the Trigger

1. In Trigger Type, leave the value set to Request.
2. In the Conditions field, enter:

A user requests that their Okta password be reset, or asks for help resetting/recovering their Okta login credentials.

This condition is how Console decides whether an incoming request should use this playbook.

Figure 4: The Trigger Type dropdown. "Request" is the default and correct choice for a user-initiated password reset.

Figure 5: The Trigger section expanded, showing the Conditions field where you describe the type of support request that will trigger this playbook.

Step 3: Write the Instructions

Click into the Instructions editor and add:

1. Determine the target user for the password reset:
   - If the requester is resetting their own password, use the requester.
   - If the request is on behalf of someone else, ask for that user's email address before proceeding.
2. Reset the user's Okta password using #Okta:Reset Password, leaving the reset email enabled so the user receives reset instructions.
3. Tell the user the password has been reset and that they should check their email for a link to set a new password.

To insert the Okta action:

1. Place your cursor where you want the action.
2. Type #.
3. Type Okta to filter the action menu.
4. Select Okta: Reset Password.

Console inserts the action as a chip: #Okta:Reset Password.

Figure 6: Typing # in the Instructions editor opens the action menu, listing all available integrations and their actions.

Figure 7: Typing #Okta filters the menu to show only Okta actions, including "Reset Password."

Step 4: Configure the Action

1. Click the #Okta:Reset Password chip.
2. Review the Details tab. The action describes the available parameters, including the target user and whether to send the reset email.
3. Open the Configure tab.
4. Check Confirm with user if you want Console to ask the requester before executing the reset.
5. Turn on Require approval only if this reset should require an approval workflow before execution.

For a beginner workflow, start with Confirm with user. It creates a useful safety pause without adding a full approval chain.

Figure 8: The action configuration panel. The Configure tab shows "Confirm with user" (checkbox) and "Require approval" (toggle).

Step 5: Test the Playbook

1. Click Test at the top of the editor.
2. In the Test this Playbook panel, keep Use Mock APIs enabled.
3. Confirm the Run as User value.
4. Optional: add context in Describe a Scenario.
5. In the message field, type:

I forgot my Okta password.

Console should select the Reset Okta Password playbook and invoke the Okta reset action. If you enabled Confirm with user, the test should include a confirmation step before the action executes.

Figure 9: The Test panel. Keep Use Mock APIs enabled while learning. Set Run as User to simulate a realistic requester.

Figure 10: Type a realistic question into the test input field to trigger the playbook.

Figure 11: After submitting, the test panel shows "Analyzing your request..." as Console processes the simulated request against the playbook logic.

Step 6: Publish

After the test behaves the way you expect, click Publish Changes.

If Console warns that an integration is not connected, connect that integration in Settings > Organization > Integrations before publishing or running the playbook in a real workspace.

Step 1: Create the Playbook

1. Go to Playbooks.
2. Click New Playbook.
3. Name the playbook Locked out of laptop.

Step 2: Set the Trigger

Use this condition:

When a user reports that they are locked out of their Mac computer, forgot their Mac password, or cannot log into their laptop.

Step 3: Write the Instructions

In the Instructions editor, add:

1. Ask the user to confirm whether this is a Mac login password issue.
   - If it is not a password issue, use #Console:Create Ticket.
2. Once the user confirms, use #Jamf:List Computers for the requester. If they have multiple computers, ask them to select which one they are having issues with.
3. Once they respond, use #Jamf:Get Computer FileVault Info for the selected computer.
4. Tell the user their FileVault key and provide specific, step-by-step instructions for using it at the Mac login screen.

Insert each action with the # menu:

• #Console:Create Ticket
• #Jamf:List Computers
• #Jamf:Get Computer FileVault Info

Figure 12: The "Locked out of laptop" playbook editor showing the trigger condition and the full instructions with action chips.

Step 4: Configure Action Safety

Click each action chip and review its configuration.

For this playbook:

• Use Confirm with user on actions where you want an explicit pause.
• Use Require approval if your organization wants a human reviewer before revealing or retrieving sensitive recovery information.

Figure 13: Clicking the #Jamf:Get Computer FileVault Info action chip opens its configuration popover with "Confirm with user" and "Require approval" options.

Step 5: Test the Flow

1. Click Test.
2. Keep Use Mock APIs enabled.
3. Type:

I forgot my Mac password and I'm locked out of my laptop.

Expected behavior:

• Console selects the locked out of laptop playbook.
• Console asks a clarifying question to confirm it is a Mac login password issue.
• After confirmation, Console invokes Jamf lookup actions.
• Console returns FileVault recovery guidance.

Step 1: Create the Playbook

1. Go to Playbooks.
2. Click New Playbook.
3. Name it Create Google Group.

Step 2: Set the Trigger

Use this condition:

If the user asks to create a new Google group, email list, distribution list, etc.

Step 3: Add the Form and Actions

In the Instructions editor, add:

1. Use #Console:Trigger Form titled "New Google Group" with these fields:
   - Group Name (input, required) -- the name of the group.
   - Group Owner (user select, required) -- the user who will be set as the owner of the group.
   - Reason for group (input, required).
   - Group Members (user multi-select, optional) -- users to be added as members.
   - Group Managers (user multi-select, optional).
   - Is this going to be public or private? (select, required).
2. Use #Google:Create Group using the name typed in the form. IMPORTANT: make sure the group is created before adding anyone to it.
3. Use #Google:Add to Group to add the specified owner with the owner role.
4. Use #Google:Add to Group to add the specified members with the member role.
5. Provide the user with a concise summary of the steps taken and whether the group was successfully created.

Insert each action with the # menu:

• #Console:Trigger Form
• #Google:Create Group
• #Google:Add to Group

Figure 14: The "Create Google Group" playbook editor showing the trigger condition and the full 5-step instructions with form fields and action chips.

Step 4: Configure Permissions

Click Configure permissions under the playbook title.

Console separates two important controls:

1. Action Scope — This controls who the playbook's actions are allowed to operate on. Options include:
   • Requester Only
   • Direct Reports of Requester
   • All Reports of Requester
   • All Users
2. Restrict Playbook — This controls who can invoke the playbook.

Figure 15: The "Configure permissions" popover. Action Scope controls who actions can operate on; Restrict Playbook controls who can invoke the playbook.

Figure 16: The Action Scope dropdown expanded, showing all four options: Requester Only, Direct Reports of Requester, All Reports of Requester, and All Users.

Figure 17: The error you will see if Action Scope is left as "Requester Only." The action detail shows: "This action is not scoped to all users, and we could not resolve a target user."

For a Google Group creation workflow, use Restrict Playbook to limit who can run the playbook, such as your IT team, help desk team, or authorized managers. Use Action Scope to limit what users or groups the actions can affect.

Step 5: Test

Use Test and provide a realistic request:

Please create a Google Group for the onboarding team.

In Describe a Scenario, you can add mock details such as:

Pretend the requested group name is onboarding-team and the owner is Jeff Geronimo.

Step 1: Start a New Policy

1. Navigate to Access Policies in the left sidebar.
2. Click New Policy.
3. In the New policy modal, choose the application first, such as Anthropic.
4. Console opens the policy editor. Rename Untitled policy to Anthropic Admin Access.

Figure 18: The Access Policies list view. Click New Policy to start. You will be prompted to choose the application first, then the policy editor opens.

Step 2: Configure Details

On the Details tab, configure:

1. Policy Visibility — Choose who can see this request option, such as Engineering.
2. MFA Verification — Decide whether the requester must complete MFA before making the request.
3. Require justification — Leave this enabled if requesters should be required to explain why they need access.
4. Access length — Choose how long users can have access. Options include: 1 hour, 1 day, 1 week, 1 month, 3 months, 6 months, 1 year, Indefinite, or User-specified dates.

Console uses access length to support time-bound access and revocation.

Step 3: Set Up Approvals

1. Click the Approvals tab.
2. Under Approval Step #1, choose the approver, such as App owner.
3. Optional: click Add Approvals to add another approval step.
4. Optional: enable Escalate if the request should escalate when it is not approved in time.

Step 4: Automate Granting Access

1. Click the Grant access tab.
2. Click Add Grant access, choose Add to Group, and select anthropic_admins.

This tells Console how to provision the access after approval.

Step 5: Automate Revoking Access

1. Click the Revoke access tab.
2. Click Add Revoke access, choose Remove from Group, and select anthropic_admins.

This tells Console how to remove access when the access period ends or the policy is revoked.

Step 6: Publish

Review every tab, then click Publish Policy.

Do not publish until:

• Visibility is correct.
• Approval routing is correct.
• Grant and revoke steps are configured.
• The target integration is connected and tested.

Step 1: Open Assistant

1. Click Assistant in the left sidebar.
2. In the chat box, enter a request.

Use a prompt that maps to actions available in your workspace. For example:

Build me a playbook that resets a user's Okta password.

Figure 19: The Assistant interface. Type a natural-language prompt describing the playbook you want to build.

Step 2: Watch the Assistant Work

The Assistant may:

1. Search available actions.
2. Check whether the relevant integration is connected.
3. Draft a playbook with trigger conditions and instructions.
4. Open the drafted playbook for review.

If the Assistant says an integration is not connected, go to Settings > Organization > Integrations and connect it before publishing or running the workflow.

Figure 20: The Assistant has created the "Reset Okta Password" playbook and opened it in the editor. The right panel shows the Assistant's explanation of what it built.

Step 3: Review the Draft

When the Assistant opens the playbook, review:

• The playbook title.
• The trigger condition.
• The instruction steps.
• Every inserted action chip.
• Action configuration, including Confirm with user and Require approval.
• Action scope and playbook restrictions.

Step 4: Refine with the Editor Assistant

Inside a playbook editor, use the Assistant panel with the prompt:

Edit, debug, and improve this playbook...

You can ask for changes such as:

Add a step to create a ticket if the Jamf action fails.

or:

Ask the user to confirm the device name before running the action.

Always test the final playbook before publishing.

Test Thoroughly

Use Test before publishing. In the test panel:

• Keep Use Mock APIs enabled while learning.
• Use Run as User to simulate a realistic requester.
• Use Describe a Scenario to create edge cases, such as:

Pretend the user has two computers assigned in Jamf.

or:

Return an internal error when searching Slack.

Use Run Log for Published Playbooks

If a published playbook fails, open the playbook and use the Playbook actions menu near Publish Changes. Select Run Log to inspect where execution got stuck.

The same menu also includes options such as:

• Versions
• Unpublish Playbook
• Move to Workspace
• Duplicate Playbook
• Delete Playbook

Figure 21: The Playbook actions menu (the "..." button next to Publish Changes) showing Versions, Run Log, Unpublish, Move, Duplicate, and Delete options.

Be Explicit in Instructions

Console can reason over natural language, but clear instructions produce better automations.

Use phrases like:

• IMPORTANT: create the group before adding members.
• If the user has multiple devices, ask which one is affected.
• If the action fails, create a ticket and summarize the failure.

Configure Safety Controls Deliberately

• Confirm with user when the requester should approve an action before it runs.
• Require approval when a human reviewer should approve the action before it runs.
• Action Scope to limit who actions can operate on.
• Restrict Playbook to limit who can invoke the playbook.

Publish Only When Ready

Before publishing, confirm:

• The trigger is specific enough.
• The instructions are complete.
• All action chips are configured.
• Tests behave as expected.
• Integrations are connected.
• Permissions and scopes match your security model.