> ## Documentation Index
> Fetch the complete documentation index at: https://docs.genesiscomputing.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Requests

> Inspect ticket and chat work Genesis is tracking — activity across Jira, Linear, ServiceNow, Azure DevOps, Slack, Teams, and Google Chat, plus per-provider health diagnostics.

## 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](/docs/Setup/Azure-DevOps-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.

<Note>
  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`.
</Note>

<Note>
  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.
</Note>

<Note>
  Activity and source-health APIs require `access_config_panel` or `manage_all_connections`, matching the provider automation setup panels they aggregate.
</Note>

## 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:

| Provider | What Health checks |
| - | - |
| **Jira** | Automation enabled, poller freshness, connection usability, recent error streak. |
| **Linear** | Automation enabled, Cursor cloud adapter gate, poll timestamps, connection usability. |
| **ServiceNow** | Automation enabled, poller or webhook intake, connection usability, recent errors. |
| **Azure DevOps** | Assignment automation enabled, connection and project configured, poller freshness, recent errors. |
| **Slack** / **Teams** / **Google Chat** | Always listed (like ticket providers). **Workspace connected** reports whether an agent is deployed to Slack, has Teams credentials, or has an active accessible Google Chat connection. Teams also reflects the server-wide `teams.enabled` kill-switch. **Intake** reports the admin-configured chat mode: `automatic` (accepted messages create Requests) or `manual promotion` (Requests are created only when a user asks the agent to track the thread). There is no poll configuration 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](/docs/Setup/Advanced-Settings#ticket-automation-settings).

See [`chat_work_tools`](/docs/Genbot-Toolkit/Additional-Tool-Groups#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

| Provider | Setup guide |
| - | - |
| Jira | [Jira Automation (Auto-Pickup)](/docs/Setup/Jira-Automation) |
| Linear | [Linear Automation (Auto-Pickup)](/docs/Setup/Linear-Automation) |
| ServiceNow | [ServiceNow Automation (Auto-Pickup)](/docs/Setup/ServiceNow-Automation) |
| Azure DevOps | [Azure DevOps Automation (Assignment Intake)](/docs/Setup/Azure-DevOps-Automation) |

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.

## Related pages

* [Jira Automation (Auto-Pickup)](/docs/Setup/Jira-Automation)
* [Linear Automation (Auto-Pickup)](/docs/Setup/Linear-Automation)
* [ServiceNow Automation (Auto-Pickup)](/docs/Setup/ServiceNow-Automation)
* [Azure DevOps Automation (Assignment Intake)](/docs/Setup/Azure-DevOps-Automation)
* [API Reference — Ticket automation endpoints](/docs/Genesis-API/API-Reference#ticket-automation-endpoints)
* [Activate Genesis Data Agents On Slack](/docs/Workspaces/Slack/Activate-Genbots-On-Slack)
* [Activate Eve in Teams (Bot Framework)](/docs/Workspaces/Microsoft-Teams/Activate-Bot-Framework-Eve-in-Teams)