IT Hub / ITSM

Purpose and map of the hub

The IT Hub is the IT operations centre based on the ITIL framework. From here you reach the service desk and NOC operational console, incident, request, problem and change management, the Knowledge Base, dashboards and reporting. It is the daily tool of operators (L1/L2/L3), team leaders and IT managers, and the access point to the service management views.

This page is organised in sections: first the hub pages (the landing page, the operational console, Change, Problem, Major Incident, Knowledge Base, Voicemail), then the cross-cutting modals used on tickets (Editor, Composer, Inspector, Taxonomies, Internal notes, Attachments, Links, Bulk actions, Playbook, KB, Dashboard, Quality Control, Historical Data). The ITOM, Events&AIOps, Operations Cockpit, IT Report Center and Customer Service pages are mentioned here but described on their own pages.

IT Hub landing page

What it is for. It is the hub’s entry page: it presents the hub quick actions and the tiles for the operational, management and reporting pages.

When to use it. At the start of your IT session, to choose the area you work on, or to launch the cross-cutting actions (KB, CMDB, Quality Control, Taxonomies).

How to open it. From the Core Home (IT Hub tile) or from the «IT Hub» toolbar on the hub’s pages.

What it shows. At the top, a hero strip with the title «IT Hub — IT operations centre · Network Operations · Service Desk · Operations & ITSM» and the hub quick actions:

Knowledge Base — opens the IT domain KB.
CMDB / Assets — opens the central CMDB.
Historical Data — opens the archived data (cold store) modal; requires a selected customer (see Historical Data).
Quality Control — visible to enabled roles; opens the quality review of closed tickets (see Quality Control).
Taxonomies — visible to administrators; opens the Ticket taxonomies modal (Ticket taxonomies).

Below, the tiles are grouped in three sections:

Operations (CORE) — three main tiles:

NOC · Network Operations — operational queue with L1/L2/L3 tier filter: monitoring, triage, investigation, escalation.
Service Desk · Support & requests — service desk queue with L1/L2/L3 tier filter: triage, reset, incident/problem, catalogue. (The internal domain remains OPS.)
Customer Service · per-customer groups — CS-* tickets on the customer’s dedicated groups (Customer Service, Enterprise Service and ICC).

Service management — three cockpits (visible to manager/director roles, *:MGR):

NOC Service Director — P1/War Room live, SLA per customer, shift coverage, escalation, team broadcast.
Service Desk Director — FCR, AHT, volumes per channel, CSAT, queue times, analyst performance.
Customer Service Director — management of the customer line over the per-customer groups.

Operational tools & Reporting — compact tiles: ITOM, Events & AIOps, Problem Management, Change Management, IT Operations Dashboard, IT Report Center, Voicemail.

Each tile shows an icon, a status badge (LIVE/NEW/…) and a feature line (tags of the main functions). At the bottom of the page is the unified bottom dock with softphone, chat and presence.

How to use it. Click the tile of the area you want; the quick actions at the top open their modals/pages. The visible tiles and actions depend on your role (RBAC): the landing page filters tiles based on your access profiles and the required tier.

What happens next. Navigation takes you to the chosen page/console; the session state (current customer/tenant) is carried over to the target pages.

Notes. Hub KPIs have been deliberately removed from the landing page: with the cross-tenant view they would not be meaningful; metrics live on the dedicated pages (NOC console, SLA dashboard, cockpits).

L1/L2/L3 operational console (NOC and Service Desk)

What it is for. It is the console for working on queued tickets, shared by NOC and Service Desk through the same layout engine. It lets you monitor the queue, select a ticket, see its detail and act with quick actions and context tools. A single screen covers the three levels (L1/L2/L3) through a tier filter.

When to use it. It is the operator’s workstation all day long: taking ownership, diagnosis, escalation, resolution.

How to open it. From the IT Hub landing page, NOC or Service Desk tiles. The Problem console (Problem Management Console) uses the same layout.

What it shows. A three-panel layout:

Queue (left) — the list of tickets, with:
- quick filters: All, P1/P2, Mine, Unassigned, + L2/L3;
- search by key, subject or CI;
- automatic refresh every 60 seconds (with last refresh time and counter).
Detail (centre) — the selected ticket with all its data; from here you open the Editor (Ticket editor) and the actions.
Tools (right) — context tabs that change with the tier.

At the top, a KPI strip. For NOC L1: Open tickets, Active P1/P2, SLA breaches, MTTR (min), Resolved today.

The quick actions (L1): Take ownership (assign to me), Escalate L2/L3 (team GRP-NOC_L2), Resolve, Open Major Incident (MIM escalation). The L1 tools: Linked CIs (CMDB explorer), Runbook (NOC L1 KB, incident playbook), Monitoring (Grafana, Alertmanager), SLA timer (time remaining), Dashboard (opens the KPI dashboard in a modal).

When you move to tier L2, KPIs, actions and tools change: KPIs Open incidents, Open P1/P2, Change window, MTTR, Root-cause pending; actions Take ownership, Escalate L3, Start RCA (5-why + timeline), Open Change (RFC → CAB), Escalate MIM; tools RCA workspace (timeline builder, 5-why template), Change mgmt (CAB calendar, new RFC), Runbook L2/L3.

At the bottom, the links to Service Topology and ITOM Health, and the bottom dock with softphone (SIP), chat and presence.

How to use it. You filter and search the queue, select a ticket (detail in the centre), act with the quick actions or open the Editor for full handling; the tools on the right give access to CMDB, runbooks, monitoring and SLA. Multiple selections enable bulk actions (Bulk actions).

What happens next. «Take ownership» assigns the ticket to you; «Escalate» moves it to the higher team; «Resolve» closes it; «Open Major Incident» starts the MIM workbench (Major Incident Workbench). Every action updates queue, KPIs, timeline and notifications.

Notes. The tier filter and the escalation matrices, team names (GRP-NOC_*, GRP-OPS-*) and queues are governed centrally; auto-refresh keeps the queue aligned without reloading the page.

Ticket editor

It is the most used window in all of exoCortex Core: we describe it in two sections.

What it is for, when and how to open it

What it is for. The Ticket editor is the panel (drawer) where you work on a single ticket: you read all its data, change its status (workflow transitions), edit its fields, comment, manage attachments and internal notes, and view SLA, timeline, linked tickets and the audit trail.

When to use it. Every time you take ownership of or update a ticket: taking ownership, progress updates, requesting information, resolution, closure.

How to open it. Click a ticket in any list (operational console, queues, search results, widgets), or use the ⌘O (Ctrl+O) shortcut, which opens a picker where you type the ticket key.

Distinctive feature — multi-ticket. The Editor handles up to 6 tickets open at the same time, each in its own tab at the top. You switch between tickets with a click or with ⌘Tab. A tab with unsaved changes shows the «dirty» indicator. You close each ticket with the «x» on its tab.

Display modes. The drawer supports three modes: docked at the side (side-by-side), wide screen (focus) and minimised to an icon (PIP) at the bottom. Esc collapses the drawer without losing its content.

What it shows: status bar and inner tabs

Below the ticket tabs, a status bar with the key attributes and quick controls: current status and transition buttons (confirm with ⌘↵); priority (Highest/High/Medium/Low/Lowest); assignee («Assign» control that opens the user picker); queue/team, type and key indicators.

The body is organised in inner tabs:

Detail — the ticket fields: subject, description (plain text), priority and the issue type’s custom fields, loaded from the catalogue and editable with the others. Save with ⌘S.
Timeline — the history of events (creation, transitions, comments, changes).
Comments — the comment history (author, date), rendered in Markdown, with the writing area and the Send comment button (active only when there is a draft).
SLA — the associated SLAs with a «live» countdown.
Linked — the linked objects (tickets, calls, chats, links) with date and origin; you add them with the Link Picker (Link tickets).
Attachments — the list of files with View, Download, Delete and upload; attachments are immutable (to «edit» one, you delete it and upload it again).
Internal notes — notes reserved for the team (Internal notes).
Audit — the lifecycle timeline.
Postmortem — the post-incident review tab, for the types that require it (Major Incident, SOC Incident).

When the ticket concerns a CI/host, PAM Console is available (zero-knowledge privileged access to the system).

How to use it and what happens next

Change status: choose the transition; the workflow advances, the timeline records the event, and notifications and automations fire (assignments, SLA, escalation).
Edit fields: edit in the Detail tab and save with ⌘S; changes are sent in one batch. Description and comments are in plain text (single source): what you write is what is saved and read back.
Comment: write in the Comments tab and send; the comment enters the history and notifies according to the notification matrix.
Manage attachments / assign: from the matching tabs/controls.

Shortcuts: ⌘O open picker · ⌘S save · ⌘↵ transition · Esc collapse · ⌘Tab next ticket.

Notes. The actions available (transitions, field editing, attachment deletion, internal note visibility) depend on your role’s permissions. The Postmortem tab appears only for the types that require it.

Composer, ticket creation

What it is for. It is the window where the operator creates a new ticket (on behalf of a user/customer or following a call/chat).

When to use it. When you open a new case: phone call to the service desk, chat request, report to monitor, manual creation of an incident/request/change.

How to open it. From the create button in lists/cockpits or with Ctrl+N. The context can be inherited from an active chat or call: reporter, subject, description, CI, attachments, related incident, type.

What it shows. A centred modal (with wide-screen focus mode and PIP at the bottom left), in three progressively revealed steps:

Identify — target project/tenant, channel, requester (reporter).
Classify — ticket type (issue type) and domain (menu filtered by the domain section), priority and category.
Detail — subject, description, specific fields, attachments, optional initial internal note.

Each step has a status indicator (to do/in progress/completed). Alongside it, the AI Copilot panel: title suggestion, priority proposal, categorisation, duplicate detection, relevant KB articles and runbooks.

How to use it. Fill in the three steps (the type determines the mandatory fields — Service requests). Multi-draft: up to 5 drafts open, saved on the server and locally, with autosave every 3 seconds. Submit with Ctrl+Enter or the button: the ticket is created; any initial internal note is added immediately afterwards. Shortcuts: Ctrl+N new draft · Ctrl+S save · Ctrl+Enter submit · Esc collapse.

What happens next. The ticket enters its type’s workflow, is routed to the right queue/team according to the domain’s routing rules, and notifications are generated. You can open the ticket straight away in the Editor (Ticket editor).

Notes. The target tenant must be specific: wildcard values (*, __ALL__) are rejected. If no domain is given, no default type is forced.

Ticket preview

What it is for. It shows a read-only ticket with preview, print and export, without opening it for editing.

When to use it. For a quick look, to print, or to copy the link to a ticket to share.

How to open it. From lists and widgets with the preview action.

What it shows. The ticket data and comments: subject, requester, status, priority, description and comment history.

How to use it. Print/export and Copy link buttons.

What happens next. No change to the data (read-only). To make changes, move to the Editor.

Notes. Comments are optional (if there are none, the view is still valid).

Ticket taxonomies

What it is for. It defines the service categories and subcategories the Composer uses to classify tickets. It is the configuration tool for the global taxonomy.

When to use it. When the administrator needs to create/edit ticket classification categories.

How to open it. From the Taxonomies action in the IT landing page hero (visible to administrators).

What it shows. The tree of global Categories/Subcategories with the existing entries and the create/edit/remove controls.

How to use it. You add or edit categories and subcategories; they populate the Composer’s «Type/Category» selector (Composer, ticket creation) and are used for routing and reporting.

What happens next. Changes become available in the Composer and in the classification tools; taxonomies are a single source.

Notes. It is an administrative function.

Internal notes

What it is for. It manages notes reserved for the team on a ticket, not visible to the requester.

When to use it. To record working information, hypotheses, contacts or sensitive details that must not appear in communication with the user.

How to open it. From the Internal notes tab of the Editor (Ticket editor).

What it shows. The list of the ticket’s internal notes with author and date, and the area to enter a new note.

How to use it. You add a note; it stays visible only to operators/teams with permission.

What happens next. The note is recorded on the ticket (a channel separate from public comments) and contributes to internal traceability.

Notes. Internal note visibility depends on role permissions.

Attachment viewer

What it is for. It lets you view, print and download a ticket’s attachments without downloading them locally to open them.

When to use it. To examine an attached file (image, PDF, log) while working on the ticket.

How to open it. From the View action in the Editor’s Attachments tab, or from wherever an attachment is shown.

What it shows. The file preview with print and download commands.

How to use it. You open the attachment, review it, and print or download it if needed.

What happens next. No change to the file (attachments are immutable).

Notes. To «edit» an attachment, delete it and upload a new version.

Link tickets

What it is for. It creates a link between tickets (typed relationship: e.g. «duplicates», «blocks», «related»).

When to use it. To relate a ticket to others (incidents to the same problem, duplicate requests, dependencies).

How to open it. From the Editor’s Linked tab.

What it shows. The link type, a search field for the target ticket (excluding the source ticket to prevent self-links) and an optional comment.

How to use it. Choose the type, search for and select the target ticket, confirm.

What happens next. The link is created and the ticket’s Linked tab reloads to show the new relationship.

Notes. The link type catalogue is a single source; self-linking is prevented.

Bulk actions

What it is for. It runs actions on several selected tickets at once: bulk closure and bulk escalation.

When to use it. To process several similar tickets in one go (e.g. close a series of cleared alerts, or escalate a group of tickets to the same team).

How to open it. Select several tickets in the queue/list and choose the bulk action.

What it shows. The list of selected tickets, the action choice (close/escalate) and the required parameters (resolution for closure, target team for escalation — provided by the context, not hard-coded).

How to use it. Confirm the action: close closes the selected tickets, escalate moves them to the next level. A valid selection is required.

What happens next. The tickets are updated in one batch; queue and KPIs reload; every change is recorded in the audit log.

Notes. The available resolutions and teams come from the tenant configuration.

Playbook launcher

What it is for. It lists and runs the playbooks/runbooks that apply to the page or ticket context.

When to use it. To apply a standard procedure (diagnosis, remediation, communication) to an incident or a CI.

How to open it. From the Playbook quick action on the management pages or from the icon registered in the bottom dock.

What it shows. The applicable playbooks filtered by domain and tag and enabled for the tenant, with the option to provide context input (e.g. affected CI).

How to use it. Choose a playbook and run it in Dry-run (simulation) or Run (real execution), reusing the playbook API.

What happens next. The run produces its effects (automatic actions, updates to the ticket/CI) and records the result.

Notes. The tenant is the session’s and you do not enter it by hand; sensitive actions are protected by barriers.

Knowledge Base

What it is for. It searches and shows Knowledge Base articles directly while you work, for quick resolution and KB deflection.

When to use it. During triage/diagnosis, to find a useful procedure or article without leaving the page.

How to open it. From the KB quick action in the operational console tools, or from the places that integrate KB search.

What it shows. A search field and the list of results; when you select an article, the article view with title, metadata and body.

How to use it. Type a query and search; open the article and read it; go back to the list with «back».

What happens next. The article can resolve the case (deflection) or provide the steps to follow; the KB also feeds the Composer’s AI Copilot suggestions.

Notes. The search endpoint is canonical; the full KB is managed on its dedicated page (Knowledge Base).

KPI Dashboard

What it is for. It opens an editorial KPI dashboard in an overlay, without opening a separate page.

When to use it. To check an area’s KPIs at a glance (e.g. NOC L1 Monitoring) while you work in the console.

How to open it. From the Open KPI Dashboard quick action in the console tools.

What it shows. The editorial report rendered from real data: KPIs, trends, breakdowns.

How to use it. Open it and review the charts and values; it replaces the old separate dashboards.

What happens next. No change to the data (read-only); closing it returns you to the console.

Notes. If the report runtime is not available, the modal fails explicitly (fail-loud), with no fake data.

Change Management

What it is for. It governs the lifecycle of infrastructure changes according to ITIL: Standard (pre-approved, no CAB), Normal (CAB approval) and Emergency (eCAB approval), with Change Freeze windows.

When to use it. To record, assess, approve and schedule changes; to manage CAB meetings and freeze windows.

How to open it. From the IT Hub landing page, Change Management tile, or from the operational console («Open Change» action at tier L2).

What it shows. A row of KPIs and four tabs:

List — the changes with status, type, risk, window and outcome.
CAB — the Change Advisory Board agenda: RFCs under discussion, participants, votes (type IT-CAB-MEETING).
Calendar Window — the calendar of change windows (monthly grid), with the «Proposed window».
Audit Trail — the trail of actions on changes.

How to use it. You create/assess a change (RFC), take it to CAB for approval and schedule the execution window; from each change you open the Editor to progress it and record approvals (Change approval (CAB)).

What happens next. A Normal Change requires CAB approval before execution; an Emergency Change follows the eCAB process (retroactive approval). During a freeze, changes cannot be approved without explicit authorisation from the Change Manager.

Notes. CAB meetings can be generated periodically; the minutes and the vote result are tracked on the related IT-CAB-MEETING.

Change approval (CAB)

What it is for. It records the approval decision on a change (typically a Normal Change in CAB).

When to use it. At CAB/eCAB, when the change is awaiting approval and you are one of the approvers.

How to open it. From the CAB tab or from the change’s Editor (Approvals tab). It is the same modal described in Approval, applied here to changes.

What it shows and how to use it. The approval chain with the steps and their status, and the decisions Approve / Reject / Request information / Delegate, with a comment. A signature, if required.

What happens next. Approval of the last step enables execution of the change in the scheduled window; a rejection sends it back; all decisions are notified and tracked.

Notes. CAB/eCAB rules and freezes affect the outcome (see Cockpits and management views/IT processes).

Problem Management Console

What it is for. It manages problems and root cause analysis (RCA), up to Known Errors with a documented workaround.

When to use it. When several incidents share a common cause, or to run a structured root cause analysis.

How to open it. From the IT Hub landing page, Problem Management tile.

What it shows. The operational console’s queue layout (KPIs, list with 60s auto-refresh), specialised for problems, with the link to the CAB calendar and to related incidents. It exposes RCA (5-why + engine) and the Known Error DB (KEDB).

How to use it. You open a problem, run the RCA (5-why template, timeline) and document root cause and workaround; from a problem you promote a Known Error and create the matching KB article.

What happens next. A published Known Error makes the workaround available to first level (KB deflection) and reduces resolution time for recurring incidents. The KEDB template collects: Symptom, Root cause, Temporary workaround, Permanent fix / related change, Impacted CIs, Related incidents.

Notes. RCA can also be started from tier L2 of the operational console («Start RCA» action).

Major Incident Workbench

What it is for. It is the dashboard for managing crises (Major Incidents): it coordinates the war room, updates, actions and closure.

When to use it. When a Major Incident is declared (manually or by an automatic rule when a P1 Incident exceeds 30 minutes).

How to open it. From the operational console’s Open/Escalate Major Incident action, or from direct links.

What it shows. The Major Incident Workbench title, the Resolve Major Incident button, the Impact panel and four tabs:

Timeline — the history of the incident’s events.
Actions — the Action items, the actions assigned during the crisis.
Comms — communications (updates to stakeholders/customer).
Postmortem — the post-incident review.

The Incident Bridge is available (Config MI / edit bridge button): link to the crisis call, Incident Commander, participants, real-time update timeline. The Linked tickets section shows the tickets linked to the incident.

How to use it. You open/update the bridge, record action items and communications, update the timeline; at closure you press Resolve Major Incident.

What happens next. On resolution a mandatory PIR (Post-Incident Review) is required, filled in on the Postmortem tab. Updates are communicated to stakeholders according to the configured communications.

Notes. Major Incident thresholds and classification (P0–P3) are configured in the Config MI modal (Major Incident configuration (Config MI)) and on the Admin MI Config page (Admin MI Config).

Major Incident configuration (Config MI)

What it is for. It configures Major Incident parameters: activation thresholds and severity classification.

When to use it. When you set up or review MIM policies.

How to open it. From the Config MI button of the Major Incident Workbench or from the Admin MI Config page (Admin MI Config).

What it shows and how to use it. The threshold parameters (e.g. the time after which a P1 Incident becomes Major) and the P0–P3 classification (Major Incident classification). You set them and save.

What happens next. The automatic Major Incident creation rules use these parameters.

Notes. It is an administrative function.

Knowledge Base

What it is for. It is the full management of the Knowledge Base: search, articles, authoring, usage analytics and administration. It feeds self-service and KB deflection.

When to use it. To search, create, update and analyse KB articles (type IT-KB).

How to open it. From the Knowledge Base action on the IT landing page or from the KB tile.

What it shows. Five tabs:

Search — article search with query field, results, query testing (to check what a user would find) and suggestions.
Articles — the list of articles with a category filter and the list of categories; New article button.
Editor — article authoring: 1-sentence summary, category, tags, body, attachments and publication status.
Analytics — usage metrics (number of articles, articles per category).
Admin — KB administration (categories, applicability by country — e.g. «IT, FR, DE»).

How to use it. You search and read; with authoring permission you create/update an article (summary, category, tags, body, attachments) and publish it; the Search tab lets you test search effectiveness; Analytics measures adoption.

What happens next. Published articles are available in the KB modal (Knowledge Base), in triage (deflection) and in self-service; applicability by country governs their visibility.

Notes. There is a public view (Domain, article and public KB) for external consultation.

Domain, article and public KB

Domain KB — the view of articles filtered by domain (IT/NOC/OPS/ITSM), reached from the hub’s KB action.
KB article — the detail/authoring page of a single article with category, tags, author and body.
Public KB — the public view of the articles intended for external readers.

Voicemail

What it is for. It collects the voice messages routed to the service desk (users / IT reports) and lets you listen to them, read the transcript and turn them into tickets.

When to use it. To handle voicemails received out of hours or when the softphone did not answer.

How to open it. From the IT Hub landing page, Voicemail tile (with unread voicemail counter).

What it shows. The voicemail inbox with audio player, AI transcription (Whisper), risk scoring (Claude) and callback built into the softphone.

How to use it. You listen to/read the voicemail, assess the risk, call the sender back with one click (softphone callback) or open a ticket from the content.

What happens next. Callback starts a call; opening a ticket takes you to the Composer with the voicemail context.

Notes. The page is shared with the linked areas (same canonical endpoint).

Quality Control

What it is for. It runs the quality review of closed tickets: documentation, ownership, SLA compliance, process, outcome and security.

When to use it. For sample-based or systematic quality checks on closed IT tickets.

How to open it. From the Quality Control action on the IT landing page (visible to roles enabled for quality control).

What it shows and how to use it. The list of closed tickets to review and the grid of quality criteria; you assess each criterion and record the review result.

What happens next. The results feed service quality indicators and can reopen/flag non-compliant tickets (QC-Gate).

Notes. It is a function reserved for quality/management roles.

Historical Data

What it is for. It lets you view archived historical data no longer in the operational database.

When to use it. To retrieve tickets/data archived beyond the operational window.

How to open it. From the Historical Data action on the IT landing page.

What it shows and how to use it. The search interface on the historical archive; it requires a selected customer (if the context is «All tenants» / *, the modal asks you to select one).

What happens next. The results are shown read-only from the cold archive.

Notes. It covers the data moved to the historical archive according to the archiving policy.

Pages linked to the hub (described elsewhere)

From the IT landing page you also reach pages covered elsewhere in this guide, which you can refer to: ITOM and Events & AIOps (NOC, Observability and ITOM), IT Operations Dashboard / Operations Cockpit and the Service Director views (Cockpits and management views), IT Report Center (Cockpits and management views/Reporting), Customer Service (Customer Service, Enterprise Service and ICC), CMDB / Assets (Asset Management and CMDB).