> For the complete documentation index, see [llms.txt](https://doc.duaer.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/guides/servicenow-ticket-process.md).

# ServiceNow ticket process: see where each incident and requested item waits

Connect ServiceNow to Duaer. It reads the states each incident or requested item goes through from the audit history, so you see where tickets wait and for how long.
## What does Duaer read from ServiceNow?

Each process source reads one table: incidents (incident) or requested items (sc_req_item). Each ticket is a case, with its steps in time order.

- Opened: when the ticket was opened and by whom.
- When the audit history (sys_audit) is readable, each state change is a step, named with the instance's own state labels (sys_choice), so states the instance added show as they are. The first assignment to someone is Assigned. Each step records who made the change.
- When it is not readable, Duaer reads only opened, resolved (resolved_at, incidents only) and closed (closed_at).
- Priority, category and assignment group come along. The steps match the service ticket process template, so waits are judged against its usual limits; refer to [process findings](/build/process-findings.md).

## How do you connect ServiceNow to Duaer?

1. In Duaer, create a ServiceNow Basic Auth API credential (instance subdomain, user and password) or a ServiceNow OAuth2 API credential. The credential used for knowledge search works as it is.
2. Give that ServiceNow user read access to the incident or requested item table. To see every state change, it also needs to read the sys_audit and sys_choice tables; by default usually only admin reads sys_audit.
3. As an owner or admin, open Data sources in the sidebar, select Add source, choose ServiceNow under CRM and service, then choose Process source.
4. Choose the credential and the table (Incidents or Requested items), then select Check instance. A table the user cannot read is named with its status code; without the audit history, the check says only opened, resolved and closed are read.
5. The mapping is fixed. Preview, set the schedule and who sees the cases, and confirm.

## How often does it read, and how much?

Each run reads tickets by last update, 100 at most, from where it stopped; a first read of many tickets finishes over several runs. A ticket updated later is read again for its new steps, and a step is never written twice. Read only: Duaer never writes to ServiceNow.

## What are the limits?

- One table per source: add incidents and requested items separately.
- Only the first assignment counts; reassigning later is not another step.
- Requested items have no resolved time, so without the audit history they show only opened and closed.
- Once the instance cleans up its audit history, earlier state changes cannot be read.
## Questions

### Does Duaer change data in ServiceNow?

No. Duaer only reads through the Table API.

### Can it share a credential with knowledge search?

Yes. Both use the same ServiceNow credentials, added separately.

## Related

- [Add a process source in Duaer](https://doc.duaer.com/build/process-sources.md)
- [See the process in your data and generate workflows in Duaer](https://doc.duaer.com/build/process.md)
- [Process findings and SOP conformance in Duaer](https://doc.duaer.com/build/process-findings.md)
- [Search ServiceNow in your knowledge base with Duaer](https://doc.duaer.com/guides/servicenow-knowledge-search.md)
- [Enterprise AI search vs process mining: what’s the difference?](https://doc.duaer.com/guides/ai-search-vs-process-mining.md)