Skip to main content
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 decides whether it is in scope. In-scope tickets become a Job made of one or more Tasks. Out-of-scope tickets are dropped silently.

​
What’s in a ticket record

The Tickets page in Command Center shows every ticket that reached 2501, including those that were deduplicated, dropped, or escalated.
Ticket details with a linked job and comments

A benchmark Runner ticket shows its description, linked job and progress comments together.

​
Ticket → job → task

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 for the lifecycle and Jobs 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.

​
Tags that change behavior

A few keywords in the ticket body or a comment change how the agent runs: The latest mode tag wins; a comment without one does not clear it. If a mode tag 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. See Agents → Execution Modes and Gateways → 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.