Understanding Console’s Access Model
How access works in Console
Console’s access model is built around a clear separation between end users and admins, with specific permissions applied within each group. This separation ensures employees can request help easily, while administrative users retain control over policies, workflows, and execution.
End users: requesting help or information
End users interact with Console to submit requests, operate workflows, or configure parts of the system based on the permissions they have been granted.
Depending on their role, end users may include:
Members: Base users who can view Playbooks and knowledge base content
Contributors: Users who can configure Playbooks and knowledge bases
Maintainers: Users who can configure Playbooks, knowledge bases, policies, and help desk
Integrators: Users who can configure the workspace and manage integrations without viewing requests
What end users cannot do:
Override admin-defined policies
Complete sensitive actions outside of approved workflows
Manage workspace-wide governance and security settings
Bypass required approvals
Admins: governing access and configuration
Admins are responsible for how Console is set up and governed within a workspace. Their role is focused on control, security, and long-term ownership rather than day-to-day request handling.
What admins can do:
Manage workspace settings
Add and remove members
Assign roles to users
Configure approval rules and policies
Connect and manage integrations
What admins are responsible for:
Defining who can build and operate workflows
Ensuring sensitive actions require appropriate approval
Maintaining visibility and oversight across requests
Admins typically configure Console initially and revisit settings as organizational needs change.
How these roles work together
A typical request in Console flows across roles and systems based on what the request requires. First, an end user submits a question or request via Slack or Microsoft Teams. Console interprets the requests and routes it through the appropriate path; referencing the knowledge base, evaluating access policies, or invoking a Playbook when needed.
If additional information is needed, Console asks follow-up questions to gather the necessary context. When approval is required, the request is routed to the appropriate manager or stakeholder.
When a request can be resolved automatically, Console completes it end to end. If it can’t be fully automated, the request becomes a ticket and is completed by an IT team member through Console’s backend, with all relevant context passed on.
Each role contributes at different stages of this process, ensuring requests are handled efficiently while maintaining the right controls and visibility.
Access boundaries and guardrails
Console’s access model is designed to enforce boundaries by default:
End users operate within predefined workflows and policies
Admins define approvals, permissions, and sensitive action requirements
Integrations and credentials are governed centrally
All actions are tracked for visibility and auditability purposes
This structure helps teams automate safely without sacrificing control.