Skip to main content
A gateway is governed by two independent prompts, each an optional override you toggle on:
  • The inbound prompt is a routing and orchestration instruction. It bridges the vocabulary of your ticketing system to your internal infrastructure, decides which tickets are in scope, and defines how a ticket turns into a sequence of tasks.
  • The outbound prompt governs what 2501 writes back to the ticket once a job finishes — the status it sets, whether it posts a comment, and whether it escalates.
Each side is independent: you can enable one, both, or neither. When a side’s override is off, the gateway falls back to its built-in default handling for that side.

​
The inbound prompt

The inbound prompt has no influence on how the agent behaves once assigned. Its job ends when a task is created. Behavioral shaping lives in Specialties and Operational Rules. (What 2501 writes back at the end of a job is the outbound prompt, not the inbound prompt.)

​
What belongs in an inbound prompt

​
Task sequencing across multiple hosts

This is where the gateway earns its value: defining the flow when resolving a ticket needs more than one task.
A well-written orchestration sequence is the difference between a ticket that is superficially resolved and one that is actually fixed across the full topology.

​
Routing conventions for special host classes

Some concerns are always handled by a dedicated host or group, regardless of how the ticket is worded.

​
Host name mappings (only when needed)

The gateway is usually smart enough to map external names to your inventory by itself. Add explicit mappings only for non-obvious cases — when external names don’t share any naming convention with your internal hostnames.

​
What does NOT belong in an inbound prompt

​
Scope gating

The inbound prompt also acts as a scope gate. Defining which kinds of requests the gateway should or should not handle means tickets outside that scope are skipped and marked with a distinct “Skipped” status. See Routing and Scope.
A skip never posts a comment and never changes the ticket’s status. Its only possible side effect on the ticket is reassignment: when the inbound override is on, your prompt may instruct that an out-of-scope ticket be escalated to another assignment group instead of dropped silently. With the inbound override off, a skip is dropped silently — no comment, no status change, no reassignment.

​
The outbound prompt

The outbound prompt acts at the end of a job, when work has finished. It governs what 2501 writes back to the ticket. With the outbound override off, the gateway’s built-in default mapping applies (for example, a successful incident is resolved). Enable the override to let the agent decide the write-back from your instructions. Because the gateway is the only writer to the ticket, the status, comment, and any reassignment land together as one coherent update.

​
What belongs in an outbound prompt

​
Status and close-code rules

Tell the gateway which external state to set for each kind of outcome. The agent maps the internal result to your ticketing system’s real states and close codes, and the gateway validates the choice against the legal states for that ticket type.

​
Comment style and visibility

Control whether 2501 posts a public comment (visible to the requester) or an internal work note, and the tone or detail of what it writes.

​
Escalation and reassignment rules

Decide when a finished job should be handed off — reassigned to another assignment group — rather than left with its current owner.
If your gateway handles more than one ticket type, write these rules per ticket type where they differ (for example, incidents resolve to a closed state, while change requests move to Review).