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 |
The user_admin role (or a sys_user create ACL) | Letting a person who exists in Ema but not yet on the instance raise their own ticket or be assigned one. | 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. |
| Cannot add people | Tickets work, but assigning someone who has no account on the instance may fail. | Grant the service account the user_admin or admin role, then use Test connection. A custom sys_user create ACL also fixes provisioning, but the check cannot see it, so the warning stays; ignore it in that case. |
| 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 "cannot add people" warning fires once per connect or Test connection run. It appears in the connect dialog and, for integration admins, on the queue's Tickets tab until the role is granted and Test connection is run again.
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.
Queue filters
ServiceNow-backed queues support most of the standard queue filters (status, priority, assignee, requester, tags, date range, and others). A few filters are available on the built-in Ema desk only and are not offered on ServiceNow-backed queues:
- Moved here from (
moved_from_tags): reads Ema's own move ledger, which records moves that went through Ema's move path. ServiceNow holds no equivalent record (a re-tag on the instance is not audited there), so this filter is not declared by ServiceNow-backed queues and is refused if sent.
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 and assignees 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 holds the user_admin or admin role, Ema provisions that record automatically, both for the person raising their own ticket and for workspace members being assigned a ticket. Without that role, a create or assign for someone the instance does not know returns a 422 with a message the member can pass on to an admin.
Connect and Test connection check for the role and show the "cannot add people" warning when it is missing or cannot be verified. Granting the role and running Test connection clears the warning.
Moving tickets from the built-in desk
Open tickets in a built-in Ema desk queue can be moved to a ServiceNow-backed queue. The move relocates each ticket by swapping its group-tag label to the ServiceNow queue's label and clearing the assignee; the ticket then lives in ServiceNow and follows the ServiceNow queue's rules from that point on.
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.
Trial workspaces
Free-trial workspaces can connect their own ServiceNow instance and use it as a queue backend. The setup path differs from a standard workspace because a trial cannot create a shared (workspace-level) ticketing connection.
Connecting your instance
Open the group's Integrations tab. Signup seeds a per-user ServiceNow connection template there; select it and enter your instance URL when prompted. Once connected, the queue bind accepts that template for trial callers.
What is and is not available
| Capability | Trial workspace |
|---|---|
| Built-in Ema desk | Available |
| Your own ServiceNow instance (per-user connection) | Available — connect on the group's Integrations tab |
| Shared ServiceNow queue (workspace-level connection) | Not available — creating a shared connection template is refused for trial workspaces |
| Moving a ticket out of a per-user queue to a different system | Not available — refused upfront because the background work that finishes the move cannot resolve a per-user credential |
Moving a ticket within the same per-user queue (a retag) works normally. Only cross-system moves out of a per-user queue are refused.
Deep links on a per-user queue
A per-user queue does not store an instance URL, so tickets in it do not carry a Source deep link back into ServiceNow. Each member's own connection supplies a different instance at execute time, so a URL captured from whoever bound the queue would be correct only for them. No link is the accurate result until tickets can carry a per-caller link of their own.
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.