App Access, Knowledge Bases, and Playbooks: What Powers Console

In this article

No headings found on page

Introduction

Console is built to handle a wide range of internal requests, but it does not treat every request the same way. Instead, Console relies on three core building blocks to determine how a request should be handled: App Access, Knowledge Base, and Playbooks.

Understanding the difference between these components helps clarify what Console does in different situations, why some requests resolve instantly, and why others involve approvals or execution steps.

Three core building blocks

At a high level, Console evaluates each request and routes it through one of three paths:

  • Knowledge Base for answering questions

  • App Access for managing permissions

  • Playbooks for handling structured workflows

Each serves a distinct purpose and is designed for a different type of request. 

Knowledge Base: answering questions

The Knowledge Base is used when an employee is asking a question rather than requesting a change.

Typical examples:

  • “What is our WiFi password?”

  • “What is our PTO policy?”

  • “How do I expense travel?”

In these cases, Console pulls answers directly from maintained knowledge articles and responds immediately. There is no approval flow and no execution step. The goal is fast, accurate answers without creating a ticket or interrupting a human.

The Knowledge Base works best for repetitive questions, policy explanations, and procedural guidelines. 

App Access: granting and removing permissions

App Access is used when a request involves changing who has access to a system.

Typical examples:

  • “Can I get access to Figma?”

  • “I need help updating permissions for Salesforce”

  • “Grant temporary Notion access to my colleague”

For these requests, Console applies predefined access policies to determine whether access is allowed, what level of access can be granted, whether approval is needed, and how long requests should last. 

App Access works best for permission changes, time-bound access, and policy-driven decisions.

Playbooks: handling structured workflows

Playbooks are used when a request involves multiple steps, logic, or execution beyond a single access change. Playbooks define what information must be collected during intake, how the request should be evaluated, what approvals are required, and what actions should be taken once conditions are met. 

Typical examples:

  • “Reset Okta MFA”

  • “Create Google Group”

  • “Locked out of laptop”

Playbooks can resolve requests automatically, route them to humans, or combine both approaches. If a request falls outside expected parameters, it can be escalated without breaking the workflow.

How Console chooses the right path

When an employee submits a request, Console determines which capability applies based on the nature of the request:

  • Questions are handled by the Knowledge Base

  • Permission changes are handled through the App Access policies 

  • Multi-step tasks are handled by Playbooks

This allows Console to resolve simple requests instantly while still supporting more complex workflows that require approvals or execution. 

In this article

No headings found on page

In this article

No headings found on page

In this article

No headings found on page

In this article

No headings found on page

What would you do with more time?

All systems operational

Copyright © 2026 Console, Inc.

What would you do with more time?

All systems operational

Copyright © 2026 Console, Inc.

What would you do with more time?

All systems operational

Copyright © 2026 Console, Inc.