How Console Manages Data, Access, and Permissions

Overview

Console is designed to understand who a user is and how they relate to systems before taking action on their behalf. By doing this, Console ensures requests are evaluated accurately and actions are executed only when they align with configured permissions and policies.

To do this effectively, Console:

• Sources employee identity and organizational data from systems of record

• Builds a unified user identity inside Console

• Defaults to a read-only state

• Deliberately expands permissions and automation over time

This approach allows automation to remain controlled, predictable, and auditable. 

How Console builds a unified user identity 

Console builds user identity by sourcing data from connected systems that already represent people and organizational structure.

Common sources include:

• An HRIS like Workday

• An identity provider such as Okta

• In some cases, directory data from Google

Console uses this information to create a corresponding unified user identity inside Console. This identity reflects where a user sits in the organization, including important context like who they report to and organizational structure.  

For a given user, Console can associate devices, tickets, applications, and group membership. This allows Console to reason about requests based on a holistic view of who the user is. 

Visualizating users and systems before taking actions

Console represents this information through a structured view of organizational resources. In the Console UI, the Resources view provides a graph of users, applications, groups, and devices. 

Together, these resources form a comprehensive view of relationships between people and systems. 

Out of the box, Console operates in read-only state. After building integrations, Console can read data, understand context, and use that context to inform its responses. At this stage, Console does not take actions in external systems. 

How automations and permissions are expanded over time

Teams expand what Console can do by connecting additional systems and configuring behavior intentionally. This includes connecting knowledge bases to answer based on internal documentation, configuring access policies that enable users to request access, and building playbooks to enable self-service workflows. 

Write access is not enabled automatically. Actions must be configured and permissions are scoped to specific workflows. As teams gain confidence, they can expand automation coverage and enable new actions.

Summary

By understanding who a user is and how they relate to systems before acting, Console keeps automation grounded in context. Teams can then build and expand workflows confidently, knowing behavior remains intentional and controlled.