> ## Documentation Index > Fetch the complete documentation index at: https://docs.2501.ai/llms.txt > Use this file to discover all available pages before exploring further. # Tickets > Key data extracted from your ITSM, translated for 2501's pipeline A **Ticket** is 2501's mirror of an incident or change request in your ITSM. It is not a copy of every field - only what the gateway needs to route, dispatch, and report back: title, description, comments, attachments, assignment group, requester, environment, priority. Once a ticket exists in 2501, the [gateway](https://docs.2501.ai/0.20/core-concepts/gateways.md) decides whether it is in scope. In-scope tickets become a [Job](https://docs.2501.ai/0.20/core-concepts/jobs.md) made of one or more [Tasks](https://docs.2501.ai/0.20/core-concepts/tasks.md). Out-of-scope tickets are dropped silently. ## What's in a ticket record | Field | Source | | - | - | | Title, body, priority | ITSM record | | Comments | ITSM record | | Attachments | ServiceNow record: images, Word documents and spreadsheets. See [Attachments](#attachments) | | Assignment group, environment | ITSM record - used as routing filters | | Requester / caller | ITSM record | | Status mirror | Updated as the job progresses | A ticket has no page of its own in Command Center. It reaches you as the source of the job it produced: open the job and its Source panel names the record, links out to it in the ITSM, and the execution timeline shows the comments both sides posted. A duplicate shows on the job it was folded into. Every ticket a gateway received, with or without a job, is listed under **Tickets** at the bottom of that gateway's page. You can filter the list by status or by whether the ticket has a job, and search it by number, description or ID. A ticket that produced no job - one still being picked up, skipped or failed - shows only there. ## Attachments For a ServiceNow incident or change request, 2501 reads the attached files before the job plans its tasks, so the tasks can use them as they use the ticket text: * **Files:** PNG and JPEG images, Word documents (`.docx`) and spreadsheets (`.xls`, `.xlsx`), of 10 MB or less. An image pasted into a field of the ticket counts too. 2501 ignores other files, such as PDF, CSV and legacy `.doc` files. * **When:** when 2501 creates the job, each time it reopens the job, and each time the job restarts for a new `@2501` comment. Each time, 2501 gets at most 10 new files, oldest first. The tasks use the text of the 10 newest files. * **Images** need the tenant's Multimodal Model. Without one, an image fails and the documents are still read. * **Failures** never stop the job. A file 2501 cannot get or read shows as failed on the job page, and the job continues without it. 2501 tries it again on the next restart or reopen. * **Safety:** 2501 gives the text of a file to its models as data, not as instructions. The job page lists each file and its state. The ServiceNow integration account needs read access to `sys_attachment` for incidents and change requests. To turn the feature off, set the `enableServiceNowAttachments` [feature toggle](https://docs.2501.ai/0.20/deployment/feature-toggles.md) to false. ## Ticket → job → task ```mermaid theme={null} flowchart TD T["Ticket
(ITSM record mirror)"] -->|"gateway parses and routes"| J["Job
(the unit of work for this ticket)"] J --> T1["Task 1
(agent A on host X)"] J --> T2["Task 2
(agent B on host Y)"] J --> TN["Task N ..."] ``` A job is at most 20 tasks. It runs them in turns: the tasks of a turn run at the same time, one per host, and the next turn starts when they have all ended. See [Agentic Flow](https://docs.2501.ai/0.20/understand/agentic-flow.md) for the lifecycle and [Jobs](https://docs.2501.ai/0.20/core-concepts/jobs.md) for orchestration details. ## Visibility back to the ITSM The gateway posts back at meaningful boundaries - never the full play-by-play: * **Public comments** with the plan, one comment after each turn of tasks, and the final outcome (success / partial / no-action explanation) * **Internal notes** for hand-offs - an escalation, or a change that failed - visible to operators in the ITSM, not to the requester See [Gateways → Comment visibility](https://docs.2501.ai/0.20/core-concepts/gateways.md#comment-visibility). ## Tags that change behavior A few keywords in the ticket body or a comment change how the agent runs: | Tag | Effect | | - | - | | `@2501:plan` | Force Plan on all the agents of this ticket's job: new tasks only read, and each change waits in a plan | | `@2501:auto` | Force Auto on all the agents of this ticket's job, also on agents in Plan. Works only when an Admin allows `@2501:auto` for the organization | | No mode command | Each new task has the mode of its agent | | `@2501:approve-plan` | Approve the last version of the plan that 2501 posted before this comment | | `@2501 ` | Once a job exists, restarts (in progress) or reopens (completed/failed) it with new instructions. On a plan that waits, asks for a change to the plan, or a question about it | | `@2501 unlink-ticket` | Detach a dedup-linked ticket so it gets its own job | Commands work in upper or lower case. The latest mode command that counts wins. A comment without one does not clear it. If a mode command arrives while the job is planning its next task, it discards the outdated proposal and replans before creating the task. A task already executing keeps its assigned mode. The commands of earlier versions still work: `@2501:investigate` is `@2501:plan`, and `@2501:remediate` is `@2501:auto`. When `@2501:auto` is not allowed, 2501 says so in the ticket. 2501 posts each version of a plan in the ticket, in the ticket's language, with the commands kept as written. Only `@2501:approve-plan` approves a plan, and an approval that changes nothing gets an answer that says why. See [Agents → Execution Modes](https://docs.2501.ai/0.20/core-concepts/agents.md#execution-modes-plan-and-auto), [Jobs → Plans](https://docs.2501.ai/0.20/core-concepts/jobs.md#plans) and [Gateways → Working with Active Jobs](https://docs.2501.ai/0.20/core-concepts/gateways.md#working-with-active-jobs). ## Reopening a finished ticket Once a ticket's job has finished, two things bring the agent back: * **An `@2501` comment** - an explicit re-request with new instructions. * **Reopening the ticket in the ITSM** - moving a ServiceNow incident back to **New** or **In Progress** (or updating it while it sits in one of those states) after the job finished. No mention needed: the platform notices that a person - not its own integration account - touched a ticket it considered done, and re-engages. On a state-driven reopen with no new instructions, the agent first **re-verifies the original symptom** before deciding whether more work is needed. Work completed before the reopen is treated as belonging to the previous run - it can't satisfy the reopened request on its own - while the agent still uses it as context. If verification shows the issue is genuinely resolved, the agent closes the ticket out again with an explanatory comment. Updates made by the platform's own ServiceNow account never trigger a reopen, so the agent's closing comments and status changes don't re-trigger itself. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.