Service Desk

Proxima Console includes a client-facing service desk that replaces the Jira Service Management customer portal. Clients create requests, track status, view SLA compliance, and export reports — all within the same console they use for infrastructure monitoring.

Architecture

Split Read/Write Design

The service desk uses a split architecture for reads and writes:

• Reads go to ClickHouse, where request data is synced from Jira by Dagster (sole ClickHouse writer, cron every 1 minute).
• Writes go directly to the Jira Service Management Cloud REST API. When a client creates a request, adds a comment, or transitions a status, the action happens in Jira immediately.
• SUP → PXD creation is handled by Temporal. Console calls the Temporal gateway after creating a SUP ticket; the workflow creates the PXD counterpart with 3-layer idempotency and retries.
• Instant visibility via PostgreSQL pending writes (Option D). After creating a ticket, a pending record with the JSM response is stored in PostgreSQL (30-minute TTL) and merged into the frontend list. Dagster fills in full data within ~1 minute. See Data Sync for the full pipeline documentation.

Key Features

• Requests list — filterable, sortable, paginated table with search, status/priority/type/assignee filters; collapsible filter panel and column editor for customizable views
• My Requests filter — toggle to show only requests created by the current user (scoped by reporter_email)
• Mark as Completed — one-click status transition button on request rows for quick resolution
• Kanban board — requests grouped by status category (To Do, In Progress, Done) with status sub-groups
• Request detail — full request view with comments, attachments, SLA data, delivery metrics, status timeline
• Create request — full-page form (/service-desk/new) with dynamic fields fetched from JSM per request type; supports raiseOnBehalfOf for user attribution
• Status transitions — execute available transitions with optional comment
• Approvals — view and submit approval decisions (approve/decline)
• Comments & attachments — add public/internal comments, upload file attachments (10 MB max)
• SLA metrics — first response and resolution SLA compliance, breach counts
• Delivery metrics — cycle time (avg/median/p90), throughput, on-time delivery percentage
• CSV export — download filtered request data as CSV (up to 10,000 rows)
• CLIENT REVIEW banner — attention indicator when requests await client review, with highlighted rows
• Organization picker — filter by mapped Jira organization
• Admin org mapping — manage client ↔ Jira organization ↔ project label mappings

Issue Key Display

Requests carry two keys:

• SUP key (e.g., SUP-123) — the client-facing key shown as the primary identifier in the requests list and detail page
• PXD key (e.g., PXD-456) — the internal engineering reference, stored as linked_issue_key and surfaced for internal users

The backend automatically resolves the SUP key from a PXD key when proxying calls to the JSM API, so clients always interact using the SUP key.

Data Model

Each request in ClickHouse includes the following key fields (in addition to standard Jira fields):

Field	Description
linked_issue_key	Cross-linked issue key (e.g., PXD engineering key)
reporter_email	Email of the user who created the request; used by the My Requests filter

Write actions (create, transition, comment) are recorded in the service_desk_actions audit table in PostgreSQL for traceability.

Client Isolation

Every ClickHouse query is scoped by project_label IN ({labels}), where labels are derived from the authenticated user's client → org mapping. This is the security boundary — a client can only see requests tagged with their project labels.

Write operations (create, comment, transition, approve) additionally validate that the target request or service desk belongs to the caller's organization mappings.

Requirements

• ClickHouse DWH with Jira data synced via n8n
• Jira Service Management Cloud instance with API access
• At least one service_desk_org_mapping configured (Admin > Service Desk)
• User must have servicedesk:read permission to view requests
• User must have servicedesk:write permission to create/comment/transition

Pages

Page	Path	Permission
Requests	/service-desk	servicedesk:read
Kanban Board	/service-desk/kanban	servicedesk:read
Request Detail	/service-desk/tickets/:issueKey	servicedesk:read
Create Request	/service-desk/new	servicedesk:write
Metrics Dashboard	/service-desk/metrics	servicedesk:read
Admin Org Mappings	/admin/service-desk	servicedeskconfig:read