Original request ·
YOUR IT SUPPORTGood work starts
Good work starts
with great support.
Everything you need to get back to what you do best.
How can we help?WE'RE ON IT
Your requests
| Request number | How we can help | Progress | Last update |
|---|
LET’S GET YOU SORTED
What can we help you with?
Choose a service. We’ll take it from here.
INTERNAL SUPPORT
Create a request Let’s move work forward.
The right context. A clear next step. One request at a time.
| Request | Requested by | Status | Assigned to | Target date |
|---|
Create a request for someone
Walk-up, phone, chat — capture it here on the requester's behalf.
Conversation
Request activity
Request details
Routing & target date
YOU’RE IN GOOD HANDS
Keep the conversation here. Your IT team has the context.
Requested by
Checklist
Request information
Related links
Attachments
Settings
Roles, catalog, AI and the hub wiring.
Organization & wiring
Permissions
Roles and access are managed in the Hub. Global Hub owners and admins have Admin access; other roles are assigned per app. View Hub permissions ↗
Demo data
Evaluation instances: seeds ~13 requests across every state using people from your directory. One-shot.
Request types
What people can ask for. Each type carries its own fields, checklist, queue, approval rule and SLA.
| Type | Queue | Approval | SLA | Fields | State |
|---|
AI (assistive)
checking where the key comes from…
Triage note on new requests, summaries and reply drafts for agents. Nothing AI does changes a ticket without a human click. Preferred: the company's key from the hub (lane AI for this app, set once under the hub's Settings → AI). The fields below are a local fallback for a desk without a hub key; the hub key wins whenever it is there. Keys never reach a browser; calls go out from this engine as single-node requests.
Slack intake …
A support channel becomes a queue: a message from a colleague becomes a request, the bot answers in the thread with the key, replies go both ways, and a ✅ on the first message marks it resolved (removing it reopens). The Slack app itself lives in the hub — one bot for notifications and intake.
Channels
| Channel | Workspace | Becomes | Last event | |
|---|---|---|---|---|
| none yet | ||||
Set-up, once
1 · In the hub (as owner) — Settings → Slack: add the Slack app's bot token and signing secret, then under Tool access assign the bot to desk.
2 · In Slack (api.slack.com → your app): Event Subscriptions → Request URL
3 · Here — Refresh from the hub, Load channels, pick the channel and what its messages become, Add. Say hello proves the wiring.
2 · In Slack (api.slack.com → your app): Event Subscriptions → Request URL
… → subscribe to bot events message.channels, message.groups, reaction_added, reaction_removed. OAuth & Permissions → bot scopes channels:history, groups:history, channels:read, groups:read, chat:write, reactions:read, reactions:write, users:read, users:read.email. Reinstall the app, then /invite @bot in the support channel.3 · Here — Refresh from the hub, Load channels, pick the channel and what its messages become, Add. Say hello proves the wiring.
Admin log
Settings and catalog changes. Ticket history lives on each ticket.
| When | Who | What |
|---|
How desk works
What happens when a directory account is deactivated?
Hub records the change independently of Desk. Desk checks every 30 seconds and adds it to an existing offboarding or creates a private Account review for centrally assigned agents. Confirm whether the person is leaving before continuing. Reactivation pauses completion until reviewed. Requests created later join the existing case. No device wipe, vendor cancellation or data deletion happens automatically.
Where do the employee’s devices and related work appear?
Agents see Person & related work beside the ticket. For offboarding, the person selected in the request is shown, even when HR filed it. Open an app section for hardware, sales, licenses, responsibilities, forms, device checks or monitored domains. Previous items are collapsed. Your permissions in each app still apply. Documents, secrets, submission answers and message contents stay in their original apps. Unavailable and restricted sources are shown explicitly.
One page, kept current with the code. If something here disagrees with the product, the page is the bug.
1 · Who is who
Desk accepts its roles only from Hub → Permissions. Active Hub owners/admins and app-specific Admins manage all tickets and settings. Agents work all tickets. Requesters see their own tickets and explicitly assigned pending approvals. The directory refreshes every 30 seconds; protected access stops if it is 60 seconds old. Your role and its source are shown in the app.
2 · Signing in
Bootstrap: the CLI identity that installed desk runs setHub and addAdminEmail; alternatively a Hub owner or admin may initialize the admin role on an empty desk. Regular access: you never sign in to desk. You sign in to the hub (passkey or SSO) and open the desk tile; the hub hands over a one-time ticket that desk redeems canister-to-canister. desk then mints its own 10-hour session token. When the Hub deactivates a person, Desk denies their access within 60 seconds and removes them from active pickers; their requests stay as history. Desk also denies access when its Hub directory snapshot expires.
3 · The catalog
Everything starts as a request type: name, the fields the form asks for, a checklist template, the queue it lands in, an approval rule, SLA targets and who may see it. Onboarding, access, hardware, "something is broken" are all just entries. Admins edit them under Settings → Catalog. Open checklist items block "resolved" — that is how a type enforces its procedure.
4 · Approval
A type can require approval by the requester's manager (from the hub attribute; e-mail, or an unambiguous display name) or by a hub group. The ticket waits on approval, the approver gets a notification with a deep link, decides in one click. Approved → the ticket becomes new in its queue and the SLA clocks start; rejected → closed for good (file a new one). Closing a waiting ticket cancels its approval. If no manager is on file, the Hub-assigned app admins are asked instead. Nobody can approve their own request — an admin re-routes it instead — and an approver's access to the ticket ends with the decision.
5 · Working a ticket
Status moves are explicit: new → open → waiting → resolved → closed, with waiting on requester, third party or approval. Replies never change status — except one case: the requester answers while we wait on them, which reopens. Internal notes and AI notes are never shown to the requester (filtered server-side, not in the UI). Every change is an event on the ticket's timeline; there is no other history.
5b · Telling the hub what a group does
desk answers the hub's hub_usesGroup: open a group in the hub and it shows what it drives here — default queues, approver groups, open requests and pending approvals. Hub separately lists central app-role grants.
6 · Notifications
desk holds no chat tokens. Assignment, replies, approvals and SLA breaches go to the hub as hub_notify (title + deep link only); the hub delivers to the bell and, if the person opted in, their chat DM. Queue notifications reach the group's members that desk knows from the directory.
7 · AI
Optional and assistive. On a new request (if auto-triage is on), a triage note (summary, suggested priority/type, clarifying questions) is added for agents. The model sees the request with sensitive fields redacted and never sees internal notes. Agents can request a summary of the timeline (stored as a note) or a reply draft (never stored, never sent). Configure any OpenAI-compatible or Anthropic endpoint under Settings → AI; the key stays in the canister.
8 · SLA
Each type sets respond within and resolve within hours; a date field (start date, last day) can override the due date. An hourly sweep nudges the assignee (or the queue) once per breach and marks it on the ticket. Resolved tickets auto-close after a configurable number of days.
9 · Slack intake
Optional. A support channel in Slack becomes a queue: every top-level message from a person becomes a request of the type chosen for that channel (the first line is the subject, the whole message the description, the sender the requester when Slack knows their e-mail). The bot answers in the thread with the key and a link; replies in the thread land on the request as comments, and replies from desk land in the thread. A ✅ on the first message resolves the request (blocked while checklist items are open, with a note in the thread); removing it reopens. Request types with sensitive fields point people to the portal form instead of asking for details in the channel. The Slack app is configured once in the hub (token and signing secret) and assigned to desk there; desk fetches the credentials every 15 minutes and verifies every incoming event against the signing secret. Several channels, even from different workspaces, can feed one desk.
Secrets & trust
| Secret | Where | Scope |
|---|---|---|
| Session token | browser localStorage + canister | 10 hours, per person; ended by sign-out, deactivation or expiry |
| Hub ticket | URL fragment, removed on load | 90 s, single use, only this backend can redeem it |
| AI API key | canister, write-only | outbound HTTPS only; cleared with one click |
| Slack bot token + signing secret | the hub; a copy in this canister, write-only, refreshed every 15 min | token: Slack API calls from this engine; secret: verifying Slack's events (5-minute timestamp window, replay-deduped) |
Gates: hub contract methods accept the hub canister only. Every read of a ticket checks requester, approver or staff role; every write checks role and ticket. Files are capped at 1.5 MB × 20 per ticket and stored in the canister. Stable state is append-only; deploys run moc --stable-compatible first.