ServiceNow-Backed Queues
A ServiceNow-backed queue is a pass-through. Tickets live in your instance, Ema reads and writes them live through the queue's ticketing connection, and Ema keeps no copy: the only thing it stores is the queue's configuration. Delete the connection and the tickets are still in ServiceNow, untouched.
That also means your instance's own rules apply. A business rule that reroutes a record, or a data policy that demands a close code, runs on Ema's writes exactly as it would on anyone else's.
What Ema needs on the instance
The service account
One account, used by every queue on the connection.
| Access | Why | Required |
|---|---|---|
Read and write on the ticket table the queues use (typically incident) | Creating, reading, and updating tickets. | Yes |
Read on label and label_entry | Listing a queue: Ema finds a queue's tickets by its reserved label. | Yes |
Read on sys_journal_field | Comment and work-note history. | Yes |
Read on sys_audit | The field-change part of the activity timeline. | Yes |
Read on sys_user | Resolving requester and assignee emails to instance users, and naming the people in the timeline. | Yes |
| The tag-writer role created by the install | Stamping a ticket with its queue label. | Yes |
Read on sys_ws_definition | Detecting the tag endpoint's path automatically at connect time. | Optional |
Read on sys_choice | Publishing the instance's request-type list so Ema (and your AI Employees) can offer it and refuse values the instance would drop. | Optional |
Write on sys_user | Letting a person who exists in Ema but not yet on the instance raise their own ticket. | Optional |
The impersonator role | Crediting comments and field changes to the person who made them instead of to the service account. | Optional |
The tag endpoint
Ema marks which queue a ticket belongs to with a reserved label (emahcm-<group-name>), never with an assignment group, so it never competes with your own routing. Writing that label has to happen server-side on the instance: a plain Table API insert into label_entry is stripped of the key that ties the row to the ticket, which leaves a label that reads as written and is invisible to the query every queue listing uses. The ticket would exist and never appear in its queue.
Connecting installs the small scripted endpoint that does this correctly, along with its role, and then calls it to confirm it answers. That install needs an account that can write system tables, which is more than the least-privilege set above. If the connecting account cannot do it, the connection still works and reports a warning; an instance admin installs the endpoint once and you paste its base path into the connection.
| Connect warning | Effect | Fix |
|---|---|---|
| Tag endpoint not detected | Tickets can be created but will not show up in their queue. | Reconnect with an account that can write system tables, or have an admin install the endpoint and paste its path. |
| Attribution unavailable | Tickets work, but comments and changes read as the integration account rather than the person. | Grant the service account the impersonator role. |
The PII egress allow-list
Configure this before the first ticket. Outbound integration calls run your Workspace's PII egress policy over both the URL and the body, and tickets carry requester emails, names, and free-text descriptions by nature. If the policy does not pass email addresses and person names for this integration, reads silently match nothing (a queue looks empty, with no error anywhere) and writes store placeholder tokens in your instance in place of real values. Allow at least email and person name for the ticketing integration as part of queue setup.
How fields map
Out of the box a queue maps onto the stock incident table:
| Ema field | ServiceNow |
|---|---|
| Title | short_description |
| Description | description |
| Request type | category |
| Status | state |
| Priority | urgency and impact |
| Requester | caller_id |
| Assignee | assigned_to |
| Public comments and internal notes | the comments and work_notes journals |
| Queue | a reserved label, never assignment_group |
| Sub-ticket link | parent_incident |
Ema can map a queue onto a different table, different states, or custom columns when your instance is customized. Two consequences of the stock mapping are worth knowing:
- Ema never writes the priority column. It sets urgency and impact, and ServiceNow computes priority from them, so the priority that comes back is the instance's answer. When it differs from what you asked for, the ticket says what the system of record saved instead.
- A state Ema has no mapping for reads as In progress, on the assumption that an unrecognized state is mid-lifecycle. Custom states are worth mapping explicitly.
Closing writes the close state along with a close code and close notes, because the stock data policy makes both mandatory. Deleting removes the record, or cancels it instead where the queue is configured that way.
Request types
Where the service account can read the instance's choice list, the queue publishes the active values of the mapped category column, the ticket form offers them, and Ema refuses anything else. That refusal matters most for AI Employees: an invented category is accepted by the Table API and then silently dropped or stored unrenderable, so the caller sees success and the value never lands. Without that read, request type is accepted as free text.
Who gets credit for a write
Every write is attributed to the person who made it, not to the service account, whenever the instance can do it: Ema resolves the actor once per request and the driver credits them inside ServiceNow, so your own audit trail names the right person. That needs the impersonator role, and both impersonating operations have to sit in the instance's Global scope, which the connect-time install handles. Without the role every write still lands, credited to the service account, and the connection warns you that it is happening.
Entries the platform itself makes (a parent closed by its last sub-ticket) are attributed to the system, and entries an AI Employee makes are attributed to Ema.
Requesters who are not on the instance yet
An Ema group is not a roster of your instance. Someone who joins the group and raises their first ticket may have no user record in ServiceNow, and the create would fail after they had filled in the form. Where the service account can write sys_user, Ema provisions that record, but only for the person raising their own ticket. Naming a different requester who does not exist on the instance stays an error.
Sub-tickets and the parent cascade
Sub-tickets use parent_incident. Closing the last open child of a parent with two or more children closes the parent, and creating or reopening a child reopens it. The cascade is one hop, best-effort, and attributed to the system, with a note on the parent explaining itself.
Two caveats on a ServiceNow queue:
- Parent and child must live on the same connection and the same table.
- A move is not audited on the record, so the activity timeline shows the accompanying unassign rather than the move itself.
Deep links
Every ticket read from an instance carries a link back to the record, shown as Source in the details rail. It uses the instance URL stored on the queue, so a queue pointed at a new instance produces links to the new one.
What's next
- Set Up a Ticket Queue for creating the connection and binding a group to it.
- Work a Ticket Queue for the day-to-day view of a queue.
- Integrations Hub for how connections work generally.