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

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 to false.

​
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: 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, Jobs → Plans 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.