ServiceNow incidents, CMDB and knowledge through conversation

What can Botify do in ServiceNow?

Most of the value is in reading, not writing. During an incident, engineers spend their first half hour stitching together the same context: which incidents are open for this group, which configuration item is affected, what it depends on, which business service sits on top, what changed recently and whether a known fix exists. Botify queries those records in parallel and summarises them, turning that half hour into a first message on the ticket.

The second job is keeping the record honest. Once the engineer agrees with the diagnosis, Botify can propose the state change and a work note, or open an incident for an alert nobody has ticketed yet. Those are writes to your system of record, so they belong behind an approval gate rather than running on their own.

Botify ships a ServiceNow connector with eleven tools. Nine read and run without approval; the two that write always pause for a person. The table below is a practical map of what you need, whichever platform you use.

Example flow: triaging a priority 1 incident

A realistic triage run chains six to eight reads before it says anything. The order matters less than the rule that every claim in the summary is backed by a record the engineer can open.

• Search active priority 1 incidents for the on-call assignment group, then fetch the newest one in full.
• Resolve the affected configuration item with get_ci and walk its relationships one level up and down with get_ci_relationships.
• Ask get_service_cis which business service the item backs, so the summary can say who is affected as well as which host is unhappy.
• Call list_changes_near_time with the incident’s start time and a 60-minute window to see which change requests were planned to start around then.
• Run search_knowledge and search_problems with the error text to find a known fix or an open problem record.
• Post one answer: suspected cause, evidence with record numbers, affected service, and a proposed next step.
• If the engineer agrees, propose update_incident_state to in progress with a work note; the run pauses until someone approves it.

Example flow: opening an incident from a monitoring alert

Alerts from Dynatrace or Splunk often arrive without a ticket. Botify that can read both the monitoring tool and ServiceNow can check whether an incident already exists for the same CI before proposing a new one, so the same outage does not end up as three tickets in three queues.

When it does propose create_incident, the approver sees the short description, priority and assignment group before anything is written. The call also carries an idempotency key that is stored in the incident’s correlation_id field, so if the network drops after ServiceNow created the record, a retry finds the existing incident instead of opening a second one.

Example flow: “has this happened before?”

The question every incident commander asks is whether this failure is new. Botify can search problems and knowledge articles with the error signature, fetch the best matches and quote the workaround, together with the incident numbers that previously hit the same CI.

Relationship questions are harder: “what else depends on this failing database?” spans several CMDB tables. Botify answers them one hop at a time, walking a CI’s parents and children with get_ci_relationships and listing the CIs behind a business service with get_service_cis, so every link in the answer is a relationship record the engineer can open. Teams licensed for ServiceNow’s MCP Server Console can also register its MCP server in Botify like any other MCP server; its tools then wait for approval on every call until an admin reviews them.

How do you keep ServiceNow data safe when Botify can write?

Treat every write as a proposal. Reading an incident cannot hurt anyone; setting fifty incidents to closed because a model misread a thread can. The safe design is a gateway between the model and the instance that checks the caller’s identity and roles, evaluates a policy for the specific tool, and pauses the run for approval when the tool writes.

Constrain what a write can express. Botify’s update_incident_state accepts only four target states (in_progress, on_hold, resolved, closed) mapped to ServiceNow’s standard incident workflow, so the model cannot invent a state code. Search filters take closed enums and bounded numbers, and the free-text assignment group rejects the ^ character that would let a model inject extra clauses into a ServiceNow encoded query.

Keep ServiceNow’s own controls in force. The connector authenticates with OAuth, so ServiceNow’s ACLs apply to every Table API call under the connected identity. Give that identity only the roles Botify needs, and keep in mind that your instance may add rules of its own: ServiceNow’s documented lifecycle, for example, asks for an on-hold reason when an incident goes on hold.

• Read tools run directly; create and update always wait for a named person to approve.
• The approver sees the tool, its risk level, a one-line summary and a preview of the exact payload.
• Every request, tool call, approval and result lands in the audit trail with the run that caused it.
• Connector credentials are per tenant, sealed with AES-256-GCM and never returned by the API.

Where does ServiceNow triage fail?

Botify inherits the quality of your CMDB. If relationships are stale or the business service map was never built, get_service_cis returns nothing useful and it cannot tell you who is affected. ServiceNow’s Common Service Data Model (CSDM) exists to model exactly those links between technology and the business services that consume it; the better your CSDM coverage, the better the impact statements.

Knowledge search is keyword search. The search_knowledge tool runs a single LIKE match against article titles and bodies, which is predictable and cheap but will miss an article that describes the same fault in different words. Encourage separate tries for the error code, the product name and the symptom.

Change correlation is by planned start time. A change that overran its window or started early can fall outside the search window, so widen it, up to a full day, when the timeline is uncertain, and treat “no changes found” as weak evidence rather than proof.

How to roll out Botify on ServiceNow

Start read-only with one assignment group and a narrow question set, prove the summaries are right, then turn on writes behind approval.

• Create a dedicated ServiceNow identity with the least privilege the read tools need, and connect it over OAuth.
• Enable only the read tools for the first weeks and compare Botify’s triage notes with what engineers concluded.
• Fix the CMDB gaps Botify exposes; missing relationships show up quickly once something queries them on every incident.
• Enable create_incident and update_incident_state with approval, and name who may approve for each team.
• Review the audit trail weekly: rejected proposals tell you where the reasoning or your data is weak.