Skip to main content

​
Overview

Requests is a unified operations view for external work Genesis has observed — polled tickets and, for Slack, Teams, and Google Chat, accepted chat messages (when automatic tracking is enabled) or conversations users explicitly promoted. It shows:
  • Activity — what work items exist, what state they are in, and what happened on each timeline.
  • Source health — available under Config → Request sources, where operators can check whether each configured source is healthy and what to fix when it is not.
Work items include Jira issues, Linear issues, ServiceNow records, Azure DevOps work items, and Slack or Microsoft Teams conversations tracked from chat — automatically when ticket_automation.auto_track_chat_requests is enabled (the default), when Azure DevOps assignment automation dispatches an assigned work item, or when an agent promotes the thread with promote_conversation_to_work. Each row shows the provider’s own status, a normalized Genesis state (working, needs_info, awaiting_review, done, failed, stalled, and others), who created the work, the assigned executor, a link to the Genesis thread when one exists, and for Slack and Teams chat-backed rows a deep link back to the originating message in that workspace when Genesis can resolve one.
Requests is rollout-gated. Set GENESIS_SHOW_WORK=TRUE (or 1, YES, or ON) on the Genesis deployment to expose Requests in the main navigation and allow direct visits to /work/. When the flag is off, the navigation entry is hidden and /work/ redirects away. The web client reads show_work from GET /api/config/frontend.
Once Requests is enabled, operators can hide it from the main sidebar under Config → Advanced Settings → UI Complexity. Agents, Blueprints, Missions, Config, Context Graph, and Apps always stay visible.
Activity and source-health APIs require access_config_panel or manage_all_connections, matching the provider automation setup panels they aggregate.

​
Activity tab

The Activity tab lists work items newest first. Use filters to narrow the view:
  • Provider — select one or more of jira, linear, servicenow, azure_devops, slack, teams, or google_chat.
  • State — select one or more normalized lifecycle states such as working, needs_info, awaiting_review, stalled, failed, done, or detected.
Requests that are waiting for a person’s action review appear ahead of other work in the list. Select one to open its request drawer and review the decision brief there. The drawer is the decision surface: reject the request, or choose Approve & apply when the action can be applied as part of approval. An approval can still be recorded when the action is not applied; the drawer reports whether the change was applied and, when it was not, the handler’s reason. Before choosing either decision, you can enter an optional decision reason in the drawer; Genesis records up to 2,000 characters with the Approve & apply or rejection decision. Click a row to open the detail drawer with the full event timeline. Events include claims, dispatches, resumes, status observations, duplicate suppressions, chat promotions, and follow-ups. Event detail is redacted to operational metadata only — prompt text and customer content stay on the permissioned thread. Items in working with no event for longer than thirty minutes display as stalled in the UI. That overlay is read-time only; it does not change provider state. Chat-backed rows use provider status conversation because Slack and Teams threads do not have Jira-style ticket statuses.

​
Source health

Open Config → Request sources to see the health summary for each source Genesis knows how to diagnose: Each source shows an ordered checklist. The first failing step is highlighted so operators can work top-down. When the ledger store is temporarily unreachable, the page renders a degraded state (ledger_degraded) instead of failing outright.

​
Chat work tracking

By default (ticket_automation.auto_track_chat_requests: true), accepted Slack, Teams, and Google Chat messages create a Request automatically. Google Chat follows the current DM episode for correlation and starts a new episode when the user sends /new. Slack Requests store a message permalink when Genesis can call Slack’s chat.getPermalink with the bot’s slack_app_token. Teams Requests store a teams.microsoft.com message URL built from tenant, conversation, and activity identifiers. Link resolution is best-effort — missing credentials, API failures, or incomplete identifiers leave the row without an external link but do not block tracking. When automatic tracking is disabled, conversations become work items only when a user asks the agent to track the thread and the agent calls promote_conversation_to_work from the chat_work_tools group. In automatic mode that tool is still available for explicit requests to split separate work in an already-tracked conversation. Admins change the intake mode under Config → Advanced Settings → ticket_automation (auto_track_chat_requests). See Advanced Settings — Ticket automation. See chat_work_tools for tool parameters and trigger phrases.

​
Cold-start setup

When no work has ever been recorded, the empty Activity view shows one setup tile per source (Jira, Linear, ServiceNow, Azure DevOps, Slack, Teams, and Google Chat). Each tile reflects its source’s current health and links to the right setup surface:
  • Ticket providers — Configure opens Config → Connections with the provider modal on its Automation tab (jira_tab=automation, linear_tab=automation, servicenow_tab=automation, or azure_devops_tab=automation). View connections seeds the saved-connections search with the provider type (?search=jira, ?search=linear, ?search=servicenow, or ?search=azure_devops).
  • Slack — Connect opens Config → Slack.
  • Teams — Connect opens Agents (Teams credentials are per agent).
  • Google Chat — Connect opens Config → Connections; use an accessible shared Google Workspace service-account connection.
The Automation tabs on Jira, Linear, ServiceNow, and Azure DevOps connection modals also include a View requests → link back to Requests.

​
Configure ticket sources

Shared connections are required for Jira, Linear, and ServiceNow automation so the poller can run without the setup user’s personal session. Azure DevOps assignment automation supports both shared and personal PAT connections; personal connections continue to run as the admin who enabled automation.