> Continuous Process Improvement > Incident Management > ServiceNow Problem Management > Data Template

Data Template: Incident Management

ServiceNow Problem Management

Incident Management Attributes (20) Incident Management Activities (13) Extraction Guides (2)

Your Incident Management Data Template

This template provides a comprehensive guide for collecting the necessary data to analyze and optimize your incident management process. It outlines essential data attributes to gather, key activities to track, and practical guidance on how to extract this information from your source system. Use this resource to build a robust event log for in-depth process analysis and improvement.

Recommended attributes to collect
Key activities to track
Extraction guidance for ServiceNow Problem Management

New to event logs? Learn how to create a process mining event log.

Download Template

Incident Management Attributes

These are the recommended data fields to include in your event log for a comprehensive analysis of your incident management process.

5 Required 4 Recommended 11 Optional

	Name	Description
	Activity Name ActivityName	The name of the specific event or task that occurred at a point in time within the incident lifecycle.
Description The Activity Name describes a specific step or status change in the incident management process, such as 'Incident Created', 'Assigned To Agent', or 'Incident Closed'. This data is typically derived from changes in key incident fields like 'State' or 'Assignment Group', or from specific log entries. This attribute is crucial for building the process map. It defines the nodes in the process graph, allowing analysts to visualize the flow of incidents, identify common pathways, discover bottlenecks between activities, and analyze process variants. The granularity and accuracy of these activity names directly impact the quality of the process analysis. Why it matters It defines the steps in the process map, which is the foundation for all process mining analysis and visualization. Where to get This is a derived attribute, typically generated by the data transformation logic based on changes in fields like `state`, `assignment_group`, and `assigned_to` in the `sys_audit` or `incident` tables. Examples Incident CreatedAssignment Group ChangedResolution ProposedIncident Closed
	Event Time EventTime	The precise timestamp indicating when the activity occurred.
Description Event Time, often known as the timestamp, records the exact date and time that an activity was completed or a status change occurred. In ServiceNow, this is typically captured in the `sys_updated_on` field for each change recorded in the audit trail. This attribute is essential for sequencing events correctly and for all time-based analysis. It is used to calculate cycle times, queue times, and durations between activities, which are fundamental for identifying bottlenecks, measuring performance against SLAs, and understanding process efficiency. The accuracy of these timestamps is critical for the validity of any duration-based metrics. Why it matters This timestamp orders all activities chronologically and enables the calculation of all duration-based metrics, like cycle times and bottlenecks. Where to get ServiceNow `sys_audit` table, field `sys_created_on` or the `sys_updated_on` field from the `incident` table for the last state. Examples 2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
	Incident ID IncidentId	The unique identifier for each incident record, serving as the primary key for tracking the entire lifecycle.
Description The Incident ID is the unique reference number assigned to every reported incident in ServiceNow. It acts as the core case identifier that links all related activities, updates, and communications from the moment an incident is created until it is closed. In process mining analysis, this ID is fundamental. It allows the tool to stitch together the sequence of events for each individual case, forming the basis for discovering process maps, analyzing variants, and calculating end-to-end durations. Without a unique Incident ID for each case, it would be impossible to trace the journey of an incident through the resolution process. Why it matters This is the essential Case ID that connects all events in an incident's lifecycle, making end-to-end process analysis possible. Where to get ServiceNow `incident` table, field `number`. Examples INC0010001INC0010045INC0010239
	Last Data Update LastDataUpdate	The timestamp indicating when the data for this record was last refreshed from the source system.
Description This attribute records the date and time of the most recent data extraction or update from ServiceNow. It is a metadata field that reflects the freshness of the data being analyzed, not an event in the process itself. This information is vital for understanding the timeliness of the analysis. It tells users how current the data is, which is important for operational dashboards and for making decisions based on recent events. It helps manage expectations about the data's relevance and recency. Why it matters It informs users about the freshness of the data, which is critical for the relevance and accuracy of the analysis. Where to get This timestamp is generated and populated by the data extraction tool or process at the time of the data load. Examples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Source System SourceSystem	The system from which this data was extracted.
Description This attribute identifies the origin of the incident data, which in this case is ServiceNow Problem Management. It is typically a static value added during the data extraction and transformation process. In environments where data from multiple systems might be combined for analysis, this field is critical for data lineage and segregation. It helps ensure that metrics and processes are analyzed within the correct context and allows analysts to compare processes across different source systems. Why it matters It provides crucial context about data origin, ensuring data lineage and enabling correct interpretation in multi-system environments. Where to get This is typically a static value added during the data extraction process. Examples ServiceNow Problem ManagementServiceNow
	Assigned To AssignedTo	The individual user or agent currently assigned to work on the incident.
Description This attribute identifies the specific support agent responsible for the incident at a given point in time. This information is critical for understanding workload distribution, agent performance, and handoffs between individuals. In analysis, 'Assigned To' helps visualize resource allocation and identify overburdened agents. It's also used in the Handoff and Reassignment dashboard to track how many times an incident changes individual owners, which can be an indicator of inefficiency or knowledge gaps. Analyzing resolution times by agent can also highlight top performers or those needing additional training. Why it matters It enables analysis of agent workload, performance, and individual handoffs, which are key to understanding resource efficiency. Where to get ServiceNow `incident` table, field `assigned_to`. Examples Beth AnglinDavid LooHoward Johnson
	Assignment Group AssignmentGroup	The support team or group responsible for handling the incident.
Description The Assignment Group represents the team of agents tasked with resolving the incident. Incidents are often routed between different groups, such as from a Level 1 help desk to a specialized Level 2 network team. This attribute is essential for analyzing inter-team handoffs and identifying systemic bottlenecks. The 'Handoff and Reassignment Rate' dashboard heavily relies on this data to show which teams are frequently involved in transfers. It also allows for performance comparisons between different support groups and helps in understanding where resolution expertise lies within the organization. Why it matters This tracks which team is responsible, enabling analysis of team performance, workload, and handoffs between groups. Where to get ServiceNow `incident` table, field `assignment_group`. Examples Service DeskNetwork SupportDatabase Administrators
	Incident State IncidentState	The current status of the incident in its lifecycle.
Description The Incident State indicates the incident's current stage, such as 'New', 'In Progress', 'On Hold', or 'Resolved'. State changes are often the primary source for generating activities in the event log for process mining. Analyzing the time spent in each state is a powerful way to identify bottlenecks. For example, a long duration in the 'On Hold' state might indicate dependencies on external factors or users. The sequence of state changes also forms the basis of the process map, showing how incidents progress toward resolution. Why it matters It tracks the incident's progress and is key to analyzing time spent in different stages and identifying process bottlenecks. Where to get ServiceNow `incident` table, field `incident_state` or `state`. Examples NewIn ProgressAwaiting User InfoResolvedClosed
	Priority Priority	The priority level of the incident, which dictates the required urgency of response.
Description Priority is a key field in ServiceNow that determines the order and speed for handling an incident. It is typically derived from the incident's impact and urgency, and it directly influences SLA targets. This attribute is fundamental for segmentation and performance analysis. The 'SLA Compliance Overview' dashboard uses Priority to assess whether high-priority incidents are being resolved within their target times. Analyzing cycle times by priority helps confirm that critical incidents are indeed being processed faster than less important ones. It is a critical dimension for almost every KPI and dashboard. Why it matters It allows for segmenting incidents by business importance, which is critical for SLA compliance monitoring and resource allocation. Where to get ServiceNow `incident` table, field `priority`. Examples 1 - Critical2 - High3 - Moderate4 - Low
	Caller CallerId	The user who initially reported the incident.
Description The Caller identifies the end-user or customer who is affected by the incident and reported it. This information provides context on who is being impacted by service disruptions. While not always central to the process flow itself, analyzing incidents by caller can reveal if specific individuals or departments are disproportionately affected by issues. This can point to training needs or localized environmental problems. It also provides a direct link to the customer for satisfaction surveys and communication. Why it matters It identifies the affected user, allowing for analysis by department or individual and providing context for user communication. Where to get ServiceNow `incident` table, field `caller_id`. Examples Abel TuterCarolina PashDon Goodliffe
	Category Category	The high-level classification of the incident, such as Hardware, Software, or Network.
Description The Category provides a broad classification of an incident's nature. This, often in combination with a subcategory, helps in routing the incident to the correct support team and is used for reporting and trend analysis. For process mining, this attribute is crucial for the 'Incident Categorization Accuracy' and 'Recurring Incident Volume' dashboards. By analyzing incidents where the category is changed mid-process, organizations can identify issues with initial triage. Filtering the process map by category can also reveal if certain types of incidents follow different resolution paths or experience unique bottlenecks. Why it matters It enables analysis of incident types, helps measure categorization accuracy, and is vital for routing and trend analysis. Where to get ServiceNow `incident` table, field `category`. Examples HardwareSoftwareNetworkDatabase
	Configuration Item ConfigurationItem	The specific IT component, service, or asset affected by the incident.
Description The Configuration Item (CI) is the asset from the Configuration Management Database (CMDB) that is affected by the incident. This could be a server, application, laptop, or network device. Analyzing incidents by CI is extremely valuable for identifying unreliable assets or services. It helps pinpoint which parts of the IT infrastructure are generating the most incidents, which can guide investment in upgrades or replacements. In process mining, filtering by CI can reveal if incidents related to critical applications are handled differently or more efficiently than others. Why it matters It identifies the affected asset, helping to pinpoint problematic components in the IT infrastructure and focusing improvement efforts. Where to get ServiceNow `incident` table, field `cmdb_ci`. Examples SAP ERP ProductionOracle DB Server 05Email Service
	Cycle Time CycleTime	The total duration from the time an incident was created until it was closed.
Description Cycle Time is a calculated metric representing the end-to-end duration of the incident management process for a single case. It is typically calculated as the difference between the 'Closed' timestamp and the 'Created' timestamp. This is one of the most fundamental KPIs in process mining, directly supporting the 'Incident Resolution Cycle Time' dashboard. Analyzing average cycle time, as well as its distribution, helps organizations measure overall efficiency, set performance baselines, and identify the impact of process changes. Slicing this metric by attributes like priority or category reveals which types of incidents take the longest to resolve. Why it matters This core KPI measures the end-to-end efficiency of the process and is used to identify long-running cases and track overall performance. Where to get Calculated by subtracting the first event timestamp from the last event timestamp for each Incident ID. Examples 2592008640001209600
	Is Reopened IsReopened	A flag indicating if an incident was reopened after being resolved.
Description This boolean flag is set to true if an incident's state was changed back to an active one (e.g., 'In Progress') after it had previously reached a 'Resolved' or 'Closed' state. This is typically identified by looking for a 'Incident Reopened' activity in the event log. Reopened incidents are a strong indicator of incomplete or ineffective resolutions. Analyzing these cases helps to identify premature closures or recurring issues that were not properly fixed the first time. A high reopen rate can negatively impact user satisfaction and team productivity, making this a key metric for quality control. Why it matters This flag identifies failures in the resolution process, highlighting incidents that required additional work after being considered resolved. Where to get Calculated by checking the sequence of activities for each incident to see if an 'open' state follows a 'resolved' state. Examples truefalse
	Is SLA Breached IsSlaBreached	A flag that indicates whether the incident resolution exceeded its SLA due date.
Description This is a calculated boolean attribute that flags incidents as having breached their Service Level Agreement. It is derived by comparing the actual resolution timestamp with the 'SLA Due Date'. If the resolution time is after the due date, the flag is set to true. This attribute is the foundation for the 'SLA Compliance Overview' dashboard and related KPIs. It simplifies analysis by converting a complex time comparison into a simple true/false dimension, making it easy to filter for all breached incidents and analyze their common characteristics, such as category, assignment group, or priority. Why it matters It simplifies SLA compliance analysis, allowing for easy filtering and deep-dive analysis of all incidents that failed to meet their targets. Where to get Calculated by comparing the 'Resolved At' timestamp with the 'SlaDueDate' timestamp. (Resolved At > SlaDueDate). Examples truefalse
	Problem ID ProblemId	The identifier of the associated Problem record if the incident is linked to a larger issue.
Description The Problem ID links an incident to a corresponding record in the Problem Management module. This is done when an incident is identified as being a symptom of a larger, underlying issue that affects multiple users or services. This linkage is critical for the 'Recurring Incident Volume' dashboard and the 'Recurring Incident Rate' KPI. It allows analysts to group incidents that stem from the same root cause, measure the full impact of a problem, and track the effectiveness of problem resolution efforts. A high number of incidents linked to problems indicates a reactive support environment. Why it matters It links incidents to a root cause, which is essential for analyzing recurring issues and measuring the impact of problem management. Where to get ServiceNow `incident` table, field `problem_id`. Examples PRB0040001PRB0040015PRB0040102
	Reassignment Count ReassignmentCount	The number of times the incident has been reassigned to a different group or agent.
Description This field tracks the total number of times an incident has been transferred between different assignment groups. It is a direct measure of process friction and is often used as a key performance indicator. This attribute is the primary driver for the 'Handoff and Reassignment Rate' dashboard and the 'Average Handoffs per Incident' KPI. A high reassignment count often indicates issues such as incorrect initial routing, lack of skills in a support tier, or unclear process ownership. Reducing this count is a common goal for process improvement initiatives as it typically leads to faster resolution times. Why it matters This directly measures process handoffs, a key indicator of inefficiency, incorrect routing, and opportunities for improvement. Where to get ServiceNow `incident` table, field `reassignment_count`. Examples 0135
	Resolution Code ResolutionCode	A code indicating how the incident was ultimately resolved.
Description The Resolution Code specifies the nature of the solution applied, for instance, whether it was solved by a user, resolved by a known error, or if a workaround was provided. This field is typically filled in by the agent upon closing the incident. This attribute directly supports the 'Resolution Type Effectiveness' dashboard. It allows for analysis of how many incidents are closed with permanent fixes versus temporary workarounds, which is a key indicator of service quality and long-term stability. A high rate of workarounds might suggest underlying problems are not being adequately addressed. Why it matters It clarifies the resolution method, enabling analysis of permanent fixes versus temporary workarounds and supporting root cause analysis. Where to get ServiceNow `incident` table, field `close_code` or a custom resolution code field. Examples Solved (Workaround)Solved (Permanently)Not Solved (User Canceled)Known Error
	Severity Severity	The level of business impact caused by the incident.
Description Severity defines how much an incident is impacting business operations. Along with urgency, it is often used to automatically calculate the incident's priority. In analysis, severity is a key dimension for the 'SLA Compliance Overview' dashboard. It helps organizations understand if they are meeting service levels for the most disruptive incidents. It provides a business-centric view of performance, complementing the operational view provided by priority. Why it matters It measures the business impact of an incident, providing a crucial dimension for prioritizing efforts and analyzing performance on critical issues. Where to get ServiceNow `incident` table, field `severity`. Examples 1 - High2 - Medium3 - Low
	SLA Due Date SlaDueDate	The target date and time by which the incident is expected to be resolved according to its SLA.
Description The SLA Due Date is a calculated timestamp that represents the resolution deadline for an incident. This date is determined by the Service Level Agreement (SLA) associated with the incident's characteristics, such as its priority. This attribute is essential for the 'SLA Compliance Overview' dashboard and the 'Critical Incident SLA Breach Rate' KPI. It serves as the benchmark against which the actual resolution time is compared. Analyzing incidents that are close to their SLA due date can help with proactive escalation and prioritization. Why it matters It defines the resolution target, making it possible to measure SLA compliance and identify incidents at risk of breaching their targets. Where to get This value is typically found in the `task_sla` table, which is related to the `incident` table. The `planned_end_time` field is the relevant timestamp. Examples 2023-05-20T17:00:00Z2023-06-01T09:00:00Z

Required Recommended Optional

Incident Management Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and optimization.

6 Recommended 7 Optional

	Activity	Description
	Assignment Group Changed	Represents a handoff where an incident is transferred from one support group to another. This is captured by observing subsequent changes to the 'assignment_group' field after its initial population.
Why it matters Frequent reassignments can signify incorrect initial routing, process complexity, or knowledge gaps. This activity is critical for measuring the 'Average Handoffs per Incident' KPI. Where to get Inferred from the 'sys_audit' table by tracking any change to the 'assignment_group' field after the initial assignment. Capture Identify each timestamped change to the 'assignment_group' field in the audit log. Event type inferred
	Incident Assigned To Group	This activity occurs when an incident is assigned to a specific support group for handling. It is a key step in the routing process and is captured by observing changes to the assignment group field.
Why it matters Tracking assignments is essential for analyzing handoffs, queue times for each group, and identifying routing inefficiencies or bottlenecks. Where to get Inferred from the 'sys_audit' table by tracking when the 'assignment_group' field on the 'incident' table is populated or changed. Capture Use the timestamp from the audit log for changes to the 'assignment_group' field. Event type inferred
	Incident Closed	This is the final activity in the lifecycle, signifying that the incident is fully resolved, confirmed, and no further action is needed. The event is captured explicitly via the closure timestamp.
Why it matters As the definitive end event, this activity is essential for calculating the total incident lifecycle duration and analyzing the time taken for post-resolution processing. Where to get The 'closed_at' timestamp on the 'incident' table serves as the explicit event timestamp. This is typically set when the 'state' field changes to 'Closed'. Capture Use the 'closed_at' timestamp from the incident record. Event type explicit
	Incident Created	Marks the beginning of the incident lifecycle when a new incident is formally logged in ServiceNow. This event is captured explicitly using the creation timestamp of the incident record.
Why it matters This is the primary start event for the process. Analyzing the time from this activity to resolution is fundamental for measuring overall cycle time and SLA compliance. Where to get The 'sys_created_on' timestamp on the 'incident' table serves as the explicit event timestamp for this activity. Capture Use the 'sys_created_on' timestamp from the incident record. Event type explicit
	Resolution Proposed	Marks the point when a support agent has implemented a fix and moved the incident to a 'Resolved' state. This is a key milestone preceding final closure.
Why it matters This activity signals the end of active work and the start of the confirmation phase. The time between this and 'Incident Closed' can reveal delays in user confirmation or verification. Where to get Inferred from the 'sys_audit' table when the 'state' field on the 'incident' table changes to 'Resolved'. The 'resolved_at' timestamp is often populated at this time. Capture Use the timestamp when the 'state' field becomes 'Resolved' or the 'resolved_at' timestamp. Event type inferred
	Work Started	Indicates that an agent has begun actively investigating or working on the incident. This is typically inferred when the incident's state changes from 'New' or 'Assigned' to an active state like 'In Progress'.
Why it matters This milestone marks the end of the initial queue time and the beginning of active resolution efforts. Measuring the time until work starts is key for bottleneck analysis. Where to get Inferred from the 'sys_audit' table by identifying when the 'state' field on the 'incident' table changes to a value representing active work, such as 'In Progress'. Capture Identify the timestamp when the 'state' field changes to 'In Progress' or a similar value. Event type inferred
	Awaiting User Confirmation	The incident is in a pending state, waiting for the user to confirm that the proposed resolution was successful. This is typically inferred from a specific state like 'Awaiting User Info' after being resolved.
Why it matters This state can be a significant bottleneck if users are slow to respond. Measuring time spent in this activity helps identify communication gaps and opportunities to automate closure. Where to get Inferred from the 'sys_audit' table by identifying a change to a specific pending state after resolution. The state name may be custom, such as 'Awaiting Caller'. Capture Identify timestamp when 'state' changes to a value indicating a wait for user input. Event type inferred
	Incident Assigned To Agent	Represents the point at which a specific agent within a support group takes ownership of the incident. This is captured by monitoring changes to the 'assigned_to' field.
Why it matters This provides a granular view of agent workload and first-contact resolution. It helps determine how long incidents wait for an individual to begin work after being assigned to a group. Where to get Inferred from the 'sys_audit' table by tracking when the 'assigned_to' field on the 'incident' table is populated or changed. Capture Use the timestamp from the audit log for changes to the 'assigned_to' field. Event type inferred
	Incident Categorized	Represents the initial classification of the incident, where fields like Category, Subcategory, and Priority are set. This event is typically inferred from the audit trail when these fields are first populated or updated shortly after creation.
Why it matters Accurate categorization is crucial for correct routing and prioritization. Tracking this activity helps analyze recategorization rates and their impact on resolution time. Where to get Inferred from the 'sys_audit' table by identifying the first change to fields like 'category', 'subcategory', or 'priority' for a given incident. Capture Identify the timestamp of the first update to classification fields in the audit log. Event type inferred
	Incident Escalated	Occurs when the priority or severity of an incident is increased, often requiring a faster response or different resources. This is inferred by detecting an upward change in the 'priority' field's value.
Why it matters Escalations often indicate that an incident is more severe than initially thought or is approaching an SLA breach. Analyzing these events helps in understanding process exceptions. Where to get Inferred from the 'sys_audit' table by identifying a change in the 'priority' field to a higher-urgency value. Capture Detect when the 'priority' field value increases (e.g., from '3 - Moderate' to '2 - High'). Event type inferred
	Incident Linked To Problem	This activity occurs when an incident is formally associated with a problem record, indicating it's part of a larger, underlying issue. This is inferred when the 'problem_id' field on the incident record is populated.
Why it matters Linking to a problem is a critical step in moving from reactive incident fixing to proactive root cause analysis. It supports the 'Recurring Incident Volume' dashboard. Where to get Inferred by detecting when the 'problem_id' reference field on the 'incident' table is populated with a value. Capture Identify the timestamp from the audit log when the 'problem_id' field is populated. Event type inferred
	Incident Reopened	Occurs when a user reports that the issue persists after it was marked as resolved. This is inferred when the incident state moves from 'Resolved' back to an active state like 'In Progress'.
Why it matters Reopened incidents indicate failed resolutions and represent rework. Tracking this activity is vital for measuring resolution quality and first-time fix rates. Where to get Inferred from the 'sys_audit' table by detecting a 'state' field transition from 'Resolved' back to an active state like 'In Progress' or 'Assigned'. Capture Identify timestamp when 'state' moves from 'Resolved' to an active value. Event type inferred
	Support Comment Added	A support agent adds a work note or a comment visible to the user. This is an explicit event logged in the incident's activity stream.
Why it matters Tracks communication and investigation efforts by the support team. Analyzing the frequency and timing of these comments provides insight into the investigation process. Where to get Captured from the 'sys_journal_field' table, which logs entries for the 'work_notes' and 'comments' fields on the 'incident' table. Capture Use the creation timestamp of journal entries where the element is 'work_notes' or 'comments'. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from ServiceNow Problem Management

Steps

Set Up ServiceNow Access: Obtain credentials for a service account in ServiceNow. This account must have read permissions (ACLs) for the incident table, the sys_audit table, and all required fields, including sys_id, number, sys_created_on, resolved_at, closed_at, assignment_group, assigned_to, priority, incident_state, state, category, subcategory, problem_id, comments, and work_notes.
Configure Node.js Environment: Ensure you have Node.js installed on the machine that will run the extraction script. Install the axios library for making HTTP requests by running npm install axios in your terminal.
Prepare the Extraction Script: Copy the provided JavaScript code into a file, for example, extract_incidents.js. Fill in the placeholder values for your ServiceNow instance URL, username, and password at the top of the script.
Define Extraction Parameters: Adjust the startDate and endDate variables in the script to define the time window for the incidents you want to extract. For initial runs, it is recommended to use a small date range, such as one week, to validate the results.
Execute the Script: Run the script from your terminal using the command node extract_incidents.js. The script will begin fetching incident data and their corresponding audit logs from the ServiceNow API.
Monitor Script Progress: The script will log progress to the console, showing how many incidents have been processed. Be aware that for large datasets, this process can take a significant amount of time due to the number of API calls required.
Process API Responses: The script programmatically iterates through each incident. For each incident, it queries the sys_audit table to retrieve its entire change history. It then processes this history to identify and timestamp the 13 required activities.
Handle Inferred Activities: The script contains logic to infer activities from field changes. For example, 'Incident Escalated' is created when the priority field's new value is lower (indicating higher priority) than its old value. 'Work Started' is identified by the first state change to 'In Progress'.
Structure the Event Log: As activities are identified, they are formatted into event log records, with each record containing the required columns: IncidentId, ActivityName, EventTime, and others.
Save the Output: Once the script completes, it will save the generated event log as a JSON file named servicenow_incident_event_log.json in the same directory. This file contains an array of all the extracted events.
Convert to CSV: For upload to ProcessMind, you may need to convert the final JSON output into a CSV file. Use a standard data tool or a simple script to transform the JSON array into a tabular CSV format, ensuring the column headers match the required attributes.

Configuration

API Endpoint: The script targets two primary ServiceNow Table API endpoints:
- https://[Your ServiceNow Instance].service-now.com/api/now/table/incident
- https://[Your ServiceNow Instance].service-now.com/api/now/table/sys_audit
Authentication: The provided script uses Basic Authentication (username and password). Ensure the service account credentials are correct and the account is active.
Date Range Filtering: The query is filtered by the incident creation date (sys_created_on). This is configured via the startDate and endDate variables in the script. It is recommended to extract 3 to 6 months of data for a meaningful analysis, but start with a smaller period for testing.
Key Query Parameters:
- sysparm_query: Used to filter records. The script constructs an encoded query string to filter incidents by creation date.
- sysparm_fields: Specifies which columns to retrieve, reducing the API payload size and improving performance.
- sysparm_limit: Manages pagination by defining the number of records to return per request. The script uses a limit of 1000, which is a common practice.
- sysparm_offset: Used in conjunction with sysparm_limit to fetch subsequent pages of data.
Performance Considerations: Querying the sys_audit table for every incident is resource-intensive. For very large ServiceNow instances, consider running the extraction during off-peak hours. The script processes incidents sequentially to avoid overwhelming the API, but this can extend the total runtime.
Prerequisites: A Node.js environment is required to execute the script. The user or service account running the extraction must have the necessary read permissions (ACLs) on the incident and sys_audit tables.

a Sample Query javascript

const axios = require('axios');
const fs = require('fs');

// --- Configuration ---
const INSTANCE_URL = 'https://[your-instance].service-now.com';
const USERNAME = '[your-username]';
const PASSWORD = '[your-password]';

// Define the date range for the extraction
const startDate = '2023-01-01 00:00:00';
const endDate = '2023-03-31 23:59:59';

const BATCH_SIZE = 1000; // Records per API call for incidents
const SOURCE_SYSTEM = 'ServiceNow';

// --- Main Extraction Logic ---
async function extractIncidentData() {
    const auth = { username: USERNAME, password: PASSWORD };
    const allEvents = [];
    let offset = 0;
    let hasMoreRecords = true;

    console.log(`Starting extraction for incidents created between ${startDate} and ${endDate}...`);

    while (hasMoreRecords) {
        try {
            // 1. Fetch a batch of incidents
            const incidentQuery = `sys_created_on>=${startDate}^sys_created_on<=${endDate}`;
            const incidentFields = [
                'sys_id', 'number', 'sys_created_on', 'resolved_at', 'closed_at',
                'assigned_to', 'assignment_group', 'priority', 'incident_state',
                'state', 'sys_updated_on'
            ].join(',');

            console.log(`Fetching incidents, offset: ${offset}...`);
            const incidentResponse = await axios.get(`${INSTANCE_URL}/api/now/table/incident`, {
                auth,
                params: {
                    sysparm_query: incidentQuery,
                    sysparm_fields: incidentFields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset
                }
            });

            const incidents = incidentResponse.data.result;
            if (incidents.length === 0) {
                hasMoreRecords = false;
                continue;
            }

            // 2. For each incident, fetch its audit trail and generate events
            for (const incident of incidents) {
                const lastDataUpdate = new Date().toISOString();

                // --- Explicit Events from Incident Table ---
                allEvents.push(createEvent(incident, 'Incident Created', incident.sys_created_on, lastDataUpdate));
                if (incident.resolved_at) {
                    allEvents.push(createEvent(incident, 'Resolution Proposed', incident.resolved_at, lastDataUpdate));
                }
                if (incident.closed_at) {
                    allEvents.push(createEvent(incident, 'Incident Closed', incident.closed_at, lastDataUpdate));
                }

                // --- Inferred Events from Audit Table ---
                const auditQuery = `documentkey=${incident.sys_id}`;
                const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
                const auditResponse = await axios.get(`${INSTANCE_URL}/api/now/table/sys_audit`, {
                    auth,
                    params: { sysparm_query: auditQuery, sysparm_fields: auditFields, sysparm_display_value: 'true' }
                });

                const auditRecords = auditResponse.data.result.sort((a, b) => new Date(a.sys_created_on) - new Date(b.sys_created_on));
                
                let isCategorized = false, isGroupAssigned = false, isAgentAssigned = false, isWorkStarted = false, isProblemLinked = false, isReopened = false;
                let lastPriority = null;
                
                for (const audit of auditRecords) {
                    const eventTime = audit.sys_created_on;
                    
                    if (!isCategorized && (audit.fieldname === 'category' || audit.fieldname === 'subcategory') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Categorized', eventTime, lastDataUpdate));
                        isCategorized = true;
                    }
                    if (!isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Group', eventTime, lastDataUpdate));
                        isGroupAssigned = true;
                    } else if (isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Assignment Group Changed', eventTime, lastDataUpdate));
                    }
                    if (!isAgentAssigned && audit.fieldname === 'assigned_to' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Agent', eventTime, lastDataUpdate));
                        isAgentAssigned = true;
                    }
                    if (!isWorkStarted && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Work Started', eventTime, lastDataUpdate));
                        isWorkStarted = true;
                    }
                    if ((audit.fieldname === 'comments' || audit.fieldname === 'work_notes') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Support Comment Added', eventTime, lastDataUpdate));
                    }
                    if (audit.fieldname === 'priority') {
                         const oldPriorityVal = parseInt(audit.oldvalue.match(/\d+/), 10);
                         const newPriorityVal = parseInt(audit.newvalue.match(/\d+/), 10);
                         if (lastPriority !== null && newPriorityVal < lastPriority) {
                             allEvents.push(createEvent(incident, 'Incident Escalated', eventTime, lastDataUpdate));
                         }
                         lastPriority = newPriorityVal;
                    }
                    if (!isProblemLinked && audit.fieldname === 'problem_id' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Linked To Problem', eventTime, lastDataUpdate));
                        isProblemLinked = true;
                    }
                    if ((audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('awaiting')) {
                         allEvents.push(createEvent(incident, 'Awaiting User Confirmation', eventTime, lastDataUpdate));
                    }
                    if (!isReopened && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && (audit.oldvalue.toLowerCase().includes('resolved') || audit.oldvalue.toLowerCase().includes('closed')) && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Incident Reopened', eventTime, lastDataUpdate));
                        isReopened = true; 
                    }
                }
            }

            offset += BATCH_SIZE;
            console.log(`Processed ${incidents.length} incidents. Total events so far: ${allEvents.length}`);

        } catch (error) {
            console.error('An error occurred:', error.response ? error.response.data : error.message);
            hasMoreRecords = false; // Stop on error
        }
    }

    // 3. Save results to a file
    fs.writeFileSync('servicenow_incident_event_log.json', JSON.stringify(allEvents, null, 2));
    console.log(`Extraction complete. ${allEvents.length} events saved to servicenow_incident_event_log.json`);
}

// --- Helper Function to create a standard event object ---
function createEvent(incident, activityName, eventTime, lastDataUpdate) {
    return {
        IncidentId: incident.number,
        ActivityName: activityName,
        EventTime: eventTime,
        SourceSystem: SOURCE_SYSTEM,
        LastDataUpdate: lastDataUpdate,
        AssignedTo: incident.assigned_to.display_value || '',
        AssignmentGroup: incident.assignment_group.display_value || '',
        Priority: incident.priority.display_value || '',
        IncidentState: incident.incident_state.display_value || incident.state.display_value || ''
    };
}

// --- Run the script ---
extractIncidentData();

Steps

Prerequisites: Ensure you have Python 3.6+ installed on your system. Install the necessary libraries using pip: pip install requests pandas.
ServiceNow Setup: Create a dedicated service account in ServiceNow for this extraction. Grant this user the itil and rest_api_explorer roles to ensure it has read access to the required tables (incident, sys_audit, sys_journal_field).
Configure the Script: Open the provided Python script. Locate the configuration section at the top and replace the placeholder values for SNOW_INSTANCE, SNOW_USER, and SNOW_PASSWORD with your ServiceNow instance URL and the service account credentials. Adjust the START_DATE and END_DATE to define the desired extraction window.
Execute the Script: Run the script from your command line using python your_script_name.py. The script will begin authenticating with ServiceNow and making API calls.
Data Retrieval: The script first fetches a list of all incidents created within the specified date range from the incident table. It then uses this list of incident IDs to retrieve all related audit history from sys_audit and all comments from sys_journal_field.
Event Log Generation: The script processes the raw data in memory. It iterates through the predefined activities, generating a distinct set of rows for each one. For example, it identifies the 'Incident Created' event from the sys_created_on field and the 'Incident Closed' event from the closed_at field. For other events, it analyzes the audit log to pinpoint state transitions, field changes, and escalations.
Attribute Mapping: For each generated event row, the script performs a lookup to enrich it with contextual attributes from the main incident record, such as the AssignmentGroup, AssignedTo, Priority, and IncidentState at the time of the event.
Data Consolidation: All individual event DataFrames (one for each activity type) are combined into a single, comprehensive event log DataFrame.
Final Transformation: The consolidated DataFrame is sorted by IncidentId and EventTime to ensure the correct chronological order of events for each case. The SourceSystem and LastDataUpdate columns are added with static values.
Export to CSV: The final event log is saved as servicenow_incident_event_log.csv in the same directory where the script was executed. This file is ready for upload into process mining software.

Configuration

ServiceNow Instance (SNOW_INSTANCE): The full URL of your ServiceNow instance, for example, https://yourcompany.service-now.com.
Credentials (SNOW_USER, SNOW_PASSWORD): Authentication details for the service account. For production environments, consider using OAuth or token-based authentication instead of basic authentication.
Date Range (START_DATE, END_DATE): Defines the time window for the extraction, based on the incident creation date. A range of 3-6 months is recommended for initial analysis to balance data volume and insight. Larger ranges will significantly increase extraction time.
API Query Parameters (sysparm_query): The script uses a sysparm_query to filter incidents by their creation date (sys_created_on). You can add more conditions here to narrow the scope, for example, active=false^company=[Your Company Sys ID] to extract only closed incidents for a specific company.
API Rate Limiting: Be aware of ServiceNow's API rate limits. The script handles pagination but does not include explicit rate limit handling. For very large instances, you may need to add time.sleep() calls between requests to avoid exceeding limits.
Required Permissions: The specified user must have read access (ACLs) to the incident, sys_audit, and sys_journal_field tables. The itil role typically provides this, but your instance may have custom access controls.

a Sample Query python

import requests
import pandas as pd
from datetime import datetime
import getpass

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your ServiceNow instance URL, e.g., class="hl-string">'https://yourinstance.service-now.com'
SNOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
class=class="hl-string">"hl-comment"># Replace with your ServiceNow user. Consider using a dedicated service account.
SNOW_USER = class="hl-string">"[Your Username]"
class=class="hl-string">"hl-comment"># It's recommended to use a secure way to handle passwords, like environment variables or a secrets manager.
class=class="hl-string">"hl-comment"># getpass is used here for interactive entry to avoid hardcoding.
SNOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># Define the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

SOURCE_SYSTEM_NAME = class="hl-string">"ServiceNow"

class=class="hl-string">"hl-comment"># --- Helper Function for Paginated API Calls ---
def fetch_all_records(url, headers, params):
    class="hl-string">"""Fetches all records from a paginated ServiceNow API endpoint."""
    all_records = []
    offset = 0
    limit = 1000
    while True:
        params[class="hl-string">'sysparm_offset'] = offset
        params[class="hl-string">'sysparm_limit'] = limit
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for bad status codes
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        all_records.extend(data)
        offset += len(data)
        print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
    return all_records

class=class="hl-string">"hl-comment"># --- Main Script ---
if __name__ == class="hl-string">"__main__":
    auth = (SNOW_USER, SNOW_PASSWORD)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 1. Fetch base Incident Data
    print(class="hl-string">"\n--- Fetching Incident Data ---")
    incident_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/incident"
    incident_query = fclass="hl-string">"sys_created_on>={START_DATE} 00:00:00^sys_created_on<={END_DATE} 23:59:59"
    incident_params = {
        class="hl-string">'sysparm_query': incident_query,
        class="hl-string">'sysparm_fields': class="hl-string">'sys_id,number,sys_created_on,closed_at,opened_at,priority,state,assignment_group,assigned_to,problem_id'
    }
    incidents_raw = fetch_all_records(incident_url, headers, auth, incident_params)
    incidents_df = pd.DataFrame(incidents_raw)
    
    if incidents_df.empty:
        print(class="hl-string">"No incidents found for the given date range. Exiting.")
        exit()

    class=class="hl-string">"hl-comment"># Map sys_id to readable values for easier processing later
    for col in [class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'problem_id']:
        if col in incidents_df.columns:
            incidents_df[col] = incidents_df[col].apply(lambda x: x[class="hl-string">'display_value'] if isinstance(x, dict) and x else None)
            
    incident_sys_ids = class="hl-string">','.join(incidents_df[class="hl-string">'sys_id'].unique())

    class=class="hl-string">"hl-comment"># 2. Fetch Audit (sys_audit) Data for these incidents
    print(class="hl-string">"\n--- Fetching Audit Data ---")
    audit_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_audit"
    audit_query = fclass="hl-string">"documentkeyIN{incident_sys_ids}"
    audit_params = {
        class="hl-string">'sysparm_query': audit_query,
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,fieldname,oldvalue,newvalue'
    }
    audit_raw = fetch_all_records(audit_url, headers, auth, audit_params)
    audit_df = pd.DataFrame(audit_raw)
    audit_df.rename(columns={class="hl-string">'documentkey': class="hl-string">'sys_id'}, inplace=True)

    class=class="hl-string">"hl-comment"># 3. Fetch Journal (comments) Data for these incidents
    print(class="hl-string">"\n--- Fetching Journal/Comment Data ---")
    journal_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_journal_field"
    journal_query = fclass="hl-string">"element_idIN{incident_sys_ids}^element=work_notes,comments"
    journal_params = {
        class="hl-string">'sysparm_query': journal_query,
        class="hl-string">'sysparm_fields': class="hl-string">'element_id,sys_created_on'
    }
    journal_raw = fetch_all_records(journal_url, headers, auth, journal_params)
    journal_df = pd.DataFrame(journal_raw)
    journal_df.rename(columns={class="hl-string">'element_id': class="hl-string">'sys_id'}, inplace=True)

    print(class="hl-string">"\n--- Processing Data and Generating Event Log ---")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Merge incident details into audit and journal logs for context
    incidents_context_df = incidents_df[[class="hl-string">'sys_id', class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    incidents_context_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId'}, inplace=True)

    if not audit_df.empty:
        audit_df = pd.merge(audit_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')
    if not journal_df.empty:
        journal_df = pd.merge(journal_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Activity: Incident Created
    created_df = incidents_df[[class="hl-string">'number', class="hl-string">'sys_created_on', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    created_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Created'
    created_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'sys_created_on': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(created_df)

    class=class="hl-string">"hl-comment"># Activity: Incident Closed
    closed_df = incidents_df[incidents_df[class="hl-string">'closed_at'].notna() & (incidents_df[class="hl-string">'closed_at'] != class="hl-string">'')].copy()
    closed_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Closed'
    closed_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'closed_at': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(closed_df.drop(columns=[class="hl-string">'sys_created_on']))

    class=class="hl-string">"hl-comment"># Process audit data for remaining activities
    if not audit_df.empty:
        audit_df.sort_values(by=[class="hl-string">'sys_id', class="hl-string">'sys_created_on'], inplace=True)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Categorized (first change to category, subcategory, or priority)
        categorized_fields = [class="hl-string">'category', class="hl-string">'subcategory', class="hl-string">'priority']
        categorized_df = audit_df[audit_df[class="hl-string">'fieldname'].isin(categorized_fields)].copy()
        categorized_df = categorized_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        categorized_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Categorized'
        event_log_frames.append(categorized_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Group
        assign_group_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assignment_group') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_group_first_df = assign_group_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_group_first_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Group'
        event_log_frames.append(assign_group_first_df)
        
        class=class="hl-string">"hl-comment"># Activity: Assignment Group Changed (subsequent changes)
        assign_group_changed_df = assign_group_df.loc[assign_group_df.index.difference(assign_group_first_df.index)]
        assign_group_changed_df[class="hl-string">'ActivityName'] = class="hl-string">'Assignment Group Changed'
        event_log_frames.append(assign_group_changed_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Agent
        assign_agent_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assigned_to') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_agent_df = assign_agent_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_agent_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Agent'
        event_log_frames.append(assign_agent_df)

        class=class="hl-string">"hl-comment"># Activity: Work Started (State changed to In Progress)
        work_started_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: The class="hl-string">'newvalue' for state is often a numeric ID. Common value for class="hl-string">'In Progress' is class="hl-string">'2'. Adjust if needed.
        work_started_df = work_started_df[work_started_df[class="hl-string">'newvalue'].isin([class="hl-string">'2', class="hl-string">'In Progress', class="hl-string">'Work in Progress'])]
        work_started_df = work_started_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        work_started_df[class="hl-string">'ActivityName'] = class="hl-string">'Work Started'
        event_log_frames.append(work_started_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Escalated (Priority increases)
        priority_map = {class="hl-string">'1 - Critical': 1, class="hl-string">'2 - High': 2, class="hl-string">'3 - Moderate': 3, class="hl-string">'4 - Low': 4, class="hl-string">'5 - Planning': 5}
        escalated_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'priority'].copy()
        escalated_df[class="hl-string">'old_priority_val'] = escalated_df[class="hl-string">'oldvalue'].map(priority_map)
        escalated_df[class="hl-string">'new_priority_val'] = escalated_df[class="hl-string">'newvalue'].map(priority_map)
        escalated_df.dropna(subset=[class="hl-string">'old_priority_val', class="hl-string">'new_priority_val'], inplace=True)
        escalated_df = escalated_df[escalated_df[class="hl-string">'new_priority_val'] < escalated_df[class="hl-string">'old_priority_val']]
        escalated_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Escalated'
        event_log_frames.append(escalated_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Linked To Problem
        linked_problem_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'problem_id') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        linked_problem_df = linked_problem_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        linked_problem_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Linked To Problem'
        event_log_frames.append(linked_problem_df)
        
        class=class="hl-string">"hl-comment"># Activity: Resolution Proposed (State changed to Resolved)
        resolved_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: Common value for class="hl-string">'Resolved' is class="hl-string">'6'. Adjust if needed.
        resolved_df = resolved_df[resolved_df[class="hl-string">'newvalue'].isin([class="hl-string">'6', class="hl-string">'Resolved'])]
        resolved_df[class="hl-string">'ActivityName'] = class="hl-string">'Resolution Proposed'
        event_log_frames.append(resolved_df)
        
        class=class="hl-string">"hl-comment"># Activity: Awaiting User Confirmation (State changed to Awaiting User Info, after resolved)
        class=class="hl-string">"hl-comment"># This logic is complex and dependent on workflow. A simplified version is shown.
        state_changes = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        state_changes[class="hl-string">'prev_state'] = state_changes.groupby(class="hl-string">'sys_id')[class="hl-string">'oldvalue'].shift(-1)
        awaiting_df = state_changes[
            (state_changes[class="hl-string">'newvalue'].isin([class="hl-string">'Awaiting User Info', class="hl-string">'3'])) & 
            (state_changes[class="hl-string">'oldvalue'].isin([class="hl-string">'Resolved', class="hl-string">'6']))
        ].copy()
        awaiting_df[class="hl-string">'ActivityName'] = class="hl-string">'Awaiting User Confirmation'
        event_log_frames.append(awaiting_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Reopened
        reopened_df = audit_df[
            (audit_df[class="hl-string">'fieldname'] == class="hl-string">'state') & 
            (audit_df[class="hl-string">'oldvalue'].isin([class="hl-string">'6', class="hl-string">'7', class="hl-string">'Resolved', class="hl-string">'Closed']))
        ].copy()
        reopened_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Reopened'
        event_log_frames.append(reopened_df)
        
    class=class="hl-string">"hl-comment"># Activity: Support Comment Added
    if not journal_df.empty:
        comment_df = journal_df.copy()
        comment_df[class="hl-string">'ActivityName'] = class="hl-string">'Support Comment Added'
        event_log_frames.append(comment_df)

    class=class="hl-string">"hl-comment"># 4. Consolidate all event dataframes
    print(class="hl-string">"\n--- Consolidating Final Event Log ---")
    final_log = pd.DataFrame()
    for df in event_log_frames:
        if class="hl-string">'sys_created_on' in df.columns:
             df.rename(columns={class="hl-string">'sys_created_on': class="hl-string">'EventTime'}, inplace=True)
        if class="hl-string">'IncidentId' not in df.columns:
            continue class=class="hl-string">"hl-comment"># Skip frames that couldn't be processed
        
        common_cols = {
            class="hl-string">'IncidentId': None,
            class="hl-string">'ActivityName': None,
            class="hl-string">'EventTime': None,
            class="hl-string">'AssignedTo': None,
            class="hl-string">'AssignmentGroup': None,
            class="hl-string">'Priority': None,
            class="hl-string">'IncidentState': None
        }
        
        class=class="hl-string">"hl-comment"># Select and reorder columns, filling missing ones with None
        current_cols = {col: None for col in common_cols.keys()}
        df_subset = df[list(set(df.columns) & set(common_cols.keys()))].copy()
        final_log = pd.concat([final_log, df_subset], ignore_index=True)

    class=class="hl-string">"hl-comment"># 5. Final Cleaning and Formatting
    final_log.dropna(subset=[class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    final_log[class="hl-string">'EventTime'] = pd.to_datetime(final_log[class="hl-string">'EventTime'])
    final_log.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTime'], inplace=True)
    
    final_log[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM_NAME
    final_log[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to the desired format
    final_log = final_log[[
        class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
        class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'IncidentState'
    ]]

    class=class="hl-string">"hl-comment"># 6. Save to CSV
    output_filename = class="hl-string">'servicenow_incident_event_log.csv'
    final_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"\nSuccessfully extracted {len(final_log)} events for {final_log['IncidentId'].nunique()} incidents.")
    print(fclass="hl-string">"Event log saved to {output_filename}")

Data Template: Incident Management

Your Incident Management Data Template

Incident Management Attributes

Incident Management Activities

Extraction Guides

Direct Extraction via ServiceNow Table REST API

Steps

Configuration

a Sample Query javascript

Python Script Extraction using ServiceNow REST API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Resolve Incidents Faster: Boost ServiceNow Efficiency Now