Telegram Integration
Proxima Console runs two distinct Telegram bots for two different audiences and jobs. They share one identity system (your Telegram account links to your Console user once) and the same RBAC — every action is scoped to what your linked account may see — but they do very different things.
| Service Desk Bot | Ops Bot | |
|---|---|---|
| Handle | @proximaservicedeskbot | @proximaopsbot |
| Who it's for | Service-desk users (clients raising / following tickets) | ProximaOps responders and client groups |
| Where it lives | 1:1 chat + the Mini App | Telegram groups (added to client / team groups) |
| What it's about | Support tickets | Infra alerts, Jira ticket activity routed to groups, and on-the-spot AI ops help |
| Identity model | per user (your linked account) | per group (the group is bound to a client or team) |
| Reach for it when… | "What's happening with my support requests?" | "Tell my team the moment something breaks or a ticket moves — and let us act and ask right in the group." |
One account, both bots: you link your Telegram account to Console once with
/link(or from the Console profile page). The Service Desk bot uses that link to know which tickets are yours; the Ops bot uses it to attribute your Acknowledge/Resolve taps and scope what you can ask. See Account Linking & Security.
1. Service Desk Bot + Mini App
The Service Desk Bot (@proximaservicedeskbot) brings the Proxima Service Desk to mobile, in two cooperating parts:
- A Mini App — a React WebView that lets a user view, create, and manage support tickets from their phone.
- The bot — handles account linking and turns Jira/JSM ticket events into per-user push notifications (a DM to the reporter/assignee when their ticket changes), with a deep link into the Mini App.
It is client-facing and per-user: a stakeholder gets pinged about their own requests and taps through to read/reply — without leaving Telegram. Full details: Service Desk Bot · Mini App.
2. Ops Bot
The Ops Bot (@proximaopsbot) is group-based and operations-focused. You add it to a Telegram group, bind the group to a Console client or team with /bind, and from then on the group receives:
- L1 alerts — when infra alerts fire, the bot pages the bound group. Internal (responder) groups get full detail + Acknowledge / Resolve buttons; client groups get a severity-gated, status-only message. Acks/resolves are attributed to the tapping user's linked account and RBAC-checked.
- Jira ticket activity — new tickets, comments, and status changes for the group's client/team, routed to the right group (and topic). (Routing is configured in Console via
/bind, replacing the legacy n8n bot — see the engineering note below.) - Reactive AI ops help — @mention the bot (or reply to it) in a bound group and it runs a read-only AI Investigator scoped to that group's client, and posts a 🤖 answer.
Full details: Ops Bot.
Which bot, when?
- A client wants to track their support tickets → Service Desk Bot + Mini App (per-user).
- You want a client's group chat to see status updates for their infra/tickets → Ops Bot,
/bind <client> --audience client. - You want a ProximaOps responder group to get full alerts and act on them → Ops Bot,
/bind <client> --audience internal. - You want a cross-client team group to receive its tickets → Ops Bot,
/bind --team <team>. - Someone in a group asks "is my prod OK?" → Ops Bot reactive AI (
@proximaopsbot ...).
The Service Desk bot is not an alerting/ops tool, and the Ops bot is not a ticket-management UI — they're deliberately separate surfaces.
Documentation map
| Page | What it covers |
|---|---|
| Service Desk Bot | Commands, the JSM webhook → per-user notifications pipeline, env vars |
| Mini App | End-user guide: pages, filters, search, create, home metrics, client switching, pinning |
| Ops Bot | Group binding (/bind, /bind --team), the L1 alert flow, the reactive AI Investigator, Jira routing, audiences, authorization |
| Account Linking & Security | The linking flow + security model (initData HMAC, JWT scoping, rate limiting) shared by both bots |
| Deployment | The deployable components, nginx/systemd/k8s, and the env vars that enable each bot |
The Ops bot's Jira-to-group routing is being migrated off the legacy n8n workflow onto Console (the source of truth for client ↔ project ↔ group ↔ team) + the temporal-workers dispatcher. Onboarding moves from n8n's /add_project to the Ops bot's /bind. See the migration plan under docs/superpowers/plans/2026-06-18-opsbot-* for the cutover.