Guides
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.
How do you connect ServiceNow to Duaer?
- 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.
- 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.
- As an owner or admin, open Data sources in the sidebar, select Add source, choose ServiceNow under CRM and service, then choose Process source.
- 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.
- 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.
In this section
Add a process source in Duaer
A process source tells Duaer where to read the steps of your cases: a CSV or XLSX file, PostgreSQL, MySQL, Microsoft SQL, Oracle, a Feishu Base or Feishu approvals. The wizard takes you through columns, mapping, a preview of issues and a schedule; after you confirm, Duaer reads new rows on that schedule.
ProcessSee the process in your data and generate workflows in Duaer
Duaer reads the steps every case went through from the tables, databases or Feishu apps you already have: where cases wait too long, where they branch and who did each step. From that it generates three kinds of workflow, Watch, Coordinate and Execute, and replays each over past days before you publish it.
ProcessProcess findings and SOP conformance in Duaer
Process findings list the steps where cases wait too long or are done again, and which kind of case they happen to most. Propose any of them as a card rule and compare the 30 days before and after it was adopted. SOP conformance compares the SOP in your knowledge base with the steps cases really took.
Knowledge baseSearch ServiceNow in your knowledge base with Duaer
Connect ServiceNow to the Duaer knowledge base. People ask about knowledge articles, incidents and requests, and find only what ServiceNow shows them.
ComparisonsEnterprise AI search vs process mining: what’s the difference?
Enterprise AI search answers “how do we do this, and where is the document?” by reading documents. Process mining answers “how does the process really run, and where does it stall?” by reading event logs from systems such as ERP and CRM. Glean is a well-known example of the first and Celonis of the second. Duaer puts knowledge answers and follow-up on due work together for mid-sized teams that need some of both.