> Continuous Process Improvement > Service Request Management > ServiceNow > Data Template

Your Service Request Management Data Template

ServiceNow

Service Request Management Attributes (22) Service Request Management Activities (14) Extraction Guides (3)

Your Service Request Management Data Template

This comprehensive data template is designed to simplify your process mining journey for Service Request Management. It provides clear guidance on the essential attributes to collect, the critical activities to track, and practical extraction guidance specific to ServiceNow. Using this template will ensure you capture all necessary data for accurate analysis and effective optimization.

Recommended attributes to collect
Key activities to track for process discovery
Step-by-step data extraction guidance

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

Download Template

Service Request Management Attributes

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

5 Required 6 Recommended 11 Optional

	Name	Description
	Activity ActivityName	The name of the specific event or task that occurred within the service request lifecycle.
Description The Activity attribute records the name of each step or status change in the service request process. This could include events like 'Request Created', 'Request Approved', 'Assigned to Agent', or 'Request Closed'. Analyzing these activities allows for the visualization of the process flow, identification of common pathways, and detection of deviations from the standard procedure. It is the foundation for understanding what actually happens during the request fulfillment process. Why it matters This is a mandatory attribute that defines the steps in the process map. It is fundamental for all process analysis, including discovering bottlenecks, rework loops, and compliance issues. Where to get Derived from changes in the 'State' or 'Stage' fields in tables like 'sc_request' or 'sc_req_item', or from the audit trail (sys_audit). Examples Service Request CreatedRequest Assigned to GroupService Request ResolvedInformation Requested from User
	Service Request ID ServiceRequestID	The unique identifier for each service request record.
Description The Service Request ID is the primary key that uniquely identifies each service request submitted by a user or system. It serves as the central thread linking all subsequent events, from initial logging to final closure. In process mining, this ID is essential for reconstructing the end-to-end journey of every single request, allowing for a complete analysis of its lifecycle. Why it matters This is the mandatory Case ID. It connects all related activities into a single process instance, enabling the analysis of process flows, variations, and cycle times. Where to get ServiceNow Request [sc_request] table, field 'number'. Examples REQ0010001REQ0010025REQ0010112
	Start Time EventTime	The timestamp indicating when an activity or event started.
Description This attribute captures the exact date and time that each activity within the service request process occurred. It provides the chronological sequence of events necessary for building the process map and performing any time-based analysis. Accurate timestamps are crucial for calculating cycle times, waiting times, and processing durations. This data enables the identification of bottlenecks, SLA breaches, and trends in performance over time. Why it matters This is a mandatory timestamp for ordering events correctly. It is the basis for all performance and duration-based analysis, including cycle time and bottleneck identification. Where to get Typically found in the 'sys_updated_on' or 'sys_created_on' fields of the relevant ServiceNow tables (e.g., sc_request, sc_task) or the audit trail (sys_audit). Examples 2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
	Last Data Update LastDataUpdate	The timestamp of the most recent data refresh or extraction.
Description This attribute indicates the date and time when the data was last extracted from the source system and loaded into the process mining tool. It provides transparency on the freshness of the data being analyzed. Analysts use this information to understand if they are looking at the most current data, which is critical for operational monitoring and real-time decision making. It helps set expectations about the recency of the insights. Why it matters Ensures users are aware of the data's freshness, which is crucial for trusting the analysis and making timely, data-driven decisions. Where to get This is a metadata field added during the data ingestion process, reflecting the timestamp of the ETL job completion. Examples 2023-10-27T04:00:00Z
	Source System SourceSystem	The system from which the data originated.
Description This attribute identifies the source system of the data, which in this case is ServiceNow. It is useful in environments where data from multiple systems is being merged for a holistic process view. For a single-source analysis, this attribute provides important context and helps in data governance and management. It ensures that any user understands the origin of the data they are analyzing. Why it matters Provides essential metadata for data governance, traceability, and context, especially when combining data from multiple enterprise systems. Where to get This is typically a static value added during the data extraction and transformation process. Examples ServiceNow
	Assigned To AssignedTo	The individual user responsible for working on the service request at a given time.
Description This attribute identifies the specific agent or technician assigned to the service request. It changes as the request is handed off between different individuals. Analyzing the 'Assigned To' field is critical for understanding workload distribution, individual performance, and the impact of handoffs on resolution times. It helps answer questions about resource utilization and identifies opportunities for training or process clarification to reduce reassignments. Why it matters Enables analysis of agent workload, performance, and handoffs. It is essential for resource management and identifying bottlenecks related to specific individuals. Where to get ServiceNow Request Item [sc_req_item] or Catalog Task [sc_task] tables, field 'assigned_to'. Examples Beth AnglinDavid LooHoward Johnson
	Assignment Group AssignmentGroup	The team or group responsible for handling the service request.
Description The Assignment Group represents the team, such as 'Service Desk', 'Network Operations', or 'Database Administration', that is responsible for a service request at a particular stage. This is a key attribute for analyzing process flow between different functional areas. By tracking changes in the Assignment Group, organizations can visualize handoffs between teams, measure queue times within each group's backlog, and identify inter-team dependencies or delays. This is crucial for optimizing cross-functional collaboration. Why it matters Tracks work distribution across teams, highlights inter-team handoffs, and helps identify team-specific bottlenecks or performance issues. Where to get ServiceNow Request Item [sc_req_item] or Catalog Task [sc_task] tables, field 'assignment_group'. Examples Service DeskIT Support L2Hardware Provisioning
	Category Category	The primary classification of the service request, such as Hardware or Software.
Description Category provides a high-level classification of the service request. This is typically used to route the request to the correct team and to report on the types of requests being submitted. In process mining, Category is a powerful tool for filtering and dimension-based analysis. It allows analysts to compare the process flows, cycle times, and automation rates for different types of requests, uncovering variations that might not be visible at an aggregate level. For example, the process for a 'Hardware' request might be fundamentally different from a 'Software' request. Why it matters Allows for powerful segmentation and comparison of processes across different service types, helping to identify category-specific issues and improvement opportunities. Where to get ServiceNow Request Item [sc_req_item] table, typically through the associated Catalog Item's [sc_cat_item] category. Examples HardwareSoftwareAccess RequestNetwork
	Met SLA MadeSLA	A boolean flag indicating if the service request was resolved within its Service Level Agreement.
Description This attribute indicates whether the service request met its defined Service Level Agreement (SLA) for resolution time. It is a critical outcome metric that directly measures service performance against commitments. Analyzing this flag helps to quantify the SLA Adherence Rate KPI. It can be used as a dimension to compare the process paths of compliant requests versus breached requests, revealing common patterns or activities that contribute to SLA failures. This is essential for proactive risk monitoring and continuous service improvement. Why it matters Directly measures performance against service commitments and allows for root cause analysis of SLA breaches by comparing compliant and non-compliant cases. Where to get ServiceNow Task SLA [task_sla] table, field 'has_breached'. The value needs to be inverted (e.g., MadeSLA = NOT has_breached). Examples truefalse
	Priority Priority	The priority level of the service request, which influences its urgency.
Description Priority is a classification that determines the relative importance and urgency of a service request. It is often determined by a combination of impact and urgency and is used to guide agents on which requests to handle first. Analyzing data by priority is essential for understanding if high-priority requests are being processed faster than low-priority ones. It allows for filtering dashboards to see if SLAs are being met for critical requests and helps in identifying if the prioritization system is effective. Why it matters Enables segmentation of requests to verify that high-priority items are processed faster. It is key for SLA analysis and resource allocation. Where to get ServiceNow Request [sc_request] or Request Item [sc_req_item] tables, field 'priority'. Examples 1 - Critical2 - High3 - Moderate4 - Low
	State State	The current operational status of the service request.
Description The State attribute indicates the current stage of the service request in its lifecycle, such as 'Open', 'Work in Progress', 'Pending', or 'Closed'. Changes in this field are often used to generate the activities for the process map. Analyzing the State is crucial for understanding how much time requests spend in specific statuses, particularly waiting or pending states. It helps in identifying queues and delays, such as time spent 'Awaiting User Information', which is a common source of prolonged cycle times. Why it matters Provides insight into the request's status at any point in time, enabling the analysis of waiting times, queues, and the duration of specific process stages. Where to get ServiceNow Request [sc_request] or Request Item [sc_req_item] tables, field 'state' or 'stage'. Examples OpenWork in ProgressAwaiting User InfoClosed Complete
	Case Cycle Time CaseCycleTime	The total time elapsed from the creation to the final closure of a service request.
Description Case Cycle Time is a calculated metric that measures the total duration of a service request, from the timestamp of the very first event to the timestamp of the very last event. It represents the full end-to-end processing time from the customer's point of view. This is a primary Key Performance Indicator (KPI) for overall process efficiency. It is used in high-level dashboards to monitor performance against targets and to analyze trends over time. It can be sliced by dimensions like Category or Priority to identify which types of requests take the longest. Why it matters This is a critical KPI that measures the end-to-end process performance. It is essential for high-level monitoring, benchmarking, and identifying areas for improvement. Where to get Calculated by subtracting the minimum 'StartTime' from the maximum 'EndTime' for each unique 'ServiceRequestID'. Examples 2 10:30:000 04:15:2210 00:05:00
	Channel ContactType	The method used by the requestor to submit the service request.
Description The Contact Type, or channel, specifies how the service request was initiated. Common channels include the service portal, email, phone call, or automated alert. Understanding the channel is important for analyzing process variations that may be influenced by the submission method. For instance, requests submitted via portal may be more structured and automated, leading to faster processing times compared to those submitted via email. This analysis helps in promoting more efficient channels. Why it matters Helps identify how different submission channels impact process efficiency, automation levels, and overall cycle times, guiding efforts to optimize user interactions. Where to get ServiceNow Request [sc_request] or Interaction [interaction] tables. The field is often named 'contact_type'. Examples PortalEmailPhoneSelf-service
	End Time EndTime	The timestamp indicating when an activity or event was completed.
Description The End Time marks the conclusion of an activity. It is the timestamp of the next activity in the sequence, effectively closing the duration of the current one. This attribute is essential for calculating how long each step in the process takes. By comparing the Start Time and End Time of an activity, analysts can calculate processing times and waiting times. This is fundamental for identifying bottlenecks, measuring resource efficiency, and monitoring performance against time-based targets. Why it matters This attribute is necessary for calculating the duration of each activity, which is a core component of performance analysis, bottleneck identification, and resource utilization studies. Where to get This is a derived attribute, calculated by taking the 'StartTime' of the subsequent event in the case. Examples 2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
	Is Automated IsAutomated	A flag that indicates if an activity was performed by a system or automation.
Description This boolean attribute distinguishes between activities performed manually by a human agent and those executed by an automated system, such as a workflow or integration. For example, 'Approval Requested' might be automated, while 'Request Assigned to Agent' might be manual. Analyzing this attribute is key to measuring and increasing the level of automation in the service request process. It helps identify which manual tasks are most time-consuming and could be candidates for future automation, thereby improving efficiency and reducing costs. Why it matters Allows for the measurement of automation rates and helps identify opportunities to automate manual tasks, leading to increased efficiency and reduced operational costs. Where to get Derived by checking if the user who performed an action (e.g., 'sys_updated_by') is a designated system or integration user. Examples truefalse
	Is First Pass Resolution IsFirstPassResolution	A flag indicating if the request was resolved on the first attempt without any reopens.
Description This calculated attribute is a boolean flag that is 'true' only if the service request was resolved and closed without ever being reopened. It is a key indicator of the quality and effectiveness of the resolution provided by the service desk. This metric directly supports the First-Pass Resolution Rate KPI. A high rate is desirable as it indicates efficiency and high-quality service, leading to better customer satisfaction. Analyzing the attributes of cases that fail first pass resolution can reveal root causes like inadequate training, poor documentation, or incorrect initial diagnosis. Why it matters Measures the quality and efficiency of the resolution process. A low first-pass resolution rate indicates underlying problems that lead to rework and customer frustration. Where to get Calculated at the case level. A case is considered a first pass resolution if its 'ReopenCount' is zero. Examples truefalse
	Is Rework IsRework	A calculated flag indicating if an activity is a repeat of a previous activity in the same case.
Description This boolean flag is calculated to identify rework loops within a service request. It is marked as 'true' if the same activity has already occurred earlier in the same case, for example, if a request is assigned to the same team twice, or if information is requested from the user multiple times. This attribute is essential for the Agent Handoffs and Rework Incidents dashboard and the Request Rework Rate KPI. It allows for the direct visualization and quantification of inefficient loops in the process, which are often hidden in aggregate data. Why it matters Directly flags and quantifies process rework, making it possible to analyze the causes and impacts of inefficient loops that increase costs and cycle times. Where to get Calculated during data transformation by checking for previous occurrences of the same activity name within the same case. Examples falsetrue
	Opened By OpenedBy	The individual who initially submitted the service request.
Description This attribute identifies the user who created the service request. While often the same as the person affected by the request, it can also be a manager, a delegate, or an automated system. Analyzing requests by the 'Opened By' user or their department helps identify patterns, such as a specific group of users who frequently submit complex or problematic requests. This can inform targeted training or highlight the need for better knowledge base articles to encourage self-service. Why it matters Helps in analyzing request patterns by user, department, or role, which can inform training initiatives and targeted process improvements. Where to get ServiceNow Request [sc_request] table, field 'opened_by'. Examples Abel TuterFred LuddyDon Goodliffe
	Processing Time ProcessingTime	The duration of time actively spent working on a specific activity.
Description Processing Time, also known as active time or handling time, is the duration spent actively performing a task. It is calculated as the difference between the End Time and Start Time of an activity. This contrasts with waiting time, where a request is idle. This metric is crucial for the Bottleneck & Queue Analysis dashboard. By aggregating processing times for each activity type, analysts can pinpoint which steps consume the most resources and effort. This helps prioritize process improvement initiatives to focus on the most time-intensive tasks. Why it matters Measures the active work duration for each activity, helping to identify the most time-consuming steps in the process and pinpointing operational bottlenecks. Where to get Calculated as 'EndTime' minus 'StartTime' for each event record. Examples 0 00:05:100 01:14:450 00:09:55
	Reopen Count ReopenCount	The number of times a service request has been reopened after being resolved.
Description This attribute is a counter that tracks how many times a service request was moved from a resolved or closed state back to an open or in-progress state. A count greater than zero indicates that the initial resolution was not successful. This metric is a direct indicator of rework and is a key component of the First-Pass Resolution Rate KPI. High reopen counts suggest issues with the quality of resolution, incomplete fulfillment, or a misunderstanding of the user's needs, all of which lead to process inefficiency and user dissatisfaction. Why it matters Quantifies rework and resolution quality. A high reopen count points to inefficiencies, poor first-time fix rates, and decreased customer satisfaction. Where to get ServiceNow Request [sc_request] or Request Item [sc_req_item] tables, field 'reopen_count'. Examples 012
	Resolution Code ResolutionCode	A code that categorizes the final resolution of the service request.
Description The Resolution Code is a structured classification of how a service request was ultimately resolved. Examples include 'Fulfilled by Automation', 'User Error', or 'No Longer Required'. This attribute is vital for the Root Cause Analysis for Delays dashboard. By correlating resolution codes with long cycle times or high rework rates, analysts can identify systemic issues. For instance, if requests with the code 'Incomplete Information' are consistently slow, it points to a problem in the initial data gathering step. Why it matters Provides structured data on resolution outcomes, enabling root cause analysis of process delays, rework, and other inefficiencies. Where to get ServiceNow Request Item [sc_req_item] or a related task table, field is commonly 'close_code' or 'resolution_code'. Examples Solved (Permanently)Not Solved (Not Reproducible)Request FulfilledCancelled by User
	Satisfaction Score SatisfactionScore	The customer satisfaction rating provided by the requestor upon closure.
Description This attribute captures the satisfaction score, often on a 1-5 scale, submitted by the end-user after their service request has been resolved. This is a direct measure of the perceived quality of service. This data is essential for the Customer Satisfaction Impact Analysis dashboard. It allows for direct correlation between process metrics, like cycle time, rework, and handoffs, and the ultimate customer experience. This helps prove the business case for process improvements by linking operational efficiency to customer outcomes. Why it matters Directly links process performance metrics to customer outcomes, helping to quantify the impact of process inefficiencies on the user experience. Where to get Typically found in a related Survey [asmt_assessment_instance] table, which is linked to the original request. Examples 5431

Required Recommended Optional

Service Request Management Activities

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

6 Recommended 8 Optional

	Activity	Description
	Information Requested from User	Occurs when the fulfillment agent requires more information from the original requestor to proceed. This is typically inferred when the request's state is changed to a value like 'Awaiting User Info'.
Why it matters This activity is crucial for the 'Requestor Information Delay Analysis' dashboard, helping to quantify time lost waiting for external input from the user. Where to get Inferred from the sc_req_item state field changing to a designated 'awaiting information' status. The change is logged in the sys_audit table. Capture Identify timestamp when sc_req_item.state changes to 'Awaiting User Info'. Event type inferred
	Request Approved	This activity signifies that the request has been officially approved and can proceed to the fulfillment stage. It is captured when an approver marks the associated approval record as 'approved'.
Why it matters This key milestone marks the transition from the approval phase to the fulfillment phase. Analyzing the time taken to reach this step is crucial for understanding pre-fulfillment delays. Where to get Inferred from the state field of the related sysapproval_approver record changing to 'approved', which subsequently triggers a state change on the sc_req_item. Capture Identify timestamp when sysapproval_approver.state becomes 'approved'. Event type inferred
	Request Assigned to Agent	This activity occurs when a specific individual agent is assigned to work on the service request. It is captured by monitoring changes to the 'Assigned to' field on the request or its fulfillment tasks.
Why it matters This is critical for measuring handoffs, calculating agent-specific workloads, and analyzing queue times before an individual starts working on a request. Where to get Inferred from a change to the assigned_to field on the sc_req_item or sc_task table. The change history is logged in the sys_audit table. Capture Track changes to the assigned_to field in sys_audit. Event type inferred
	Service Request Closed	Marks the final, definitive end of the service request lifecycle. This typically occurs automatically after a set period of time in the 'Resolved' state, during which the user can reopen the request.
Why it matters This is the primary successful end event for the process. The time between 'Resolved' and 'Closed' can also be analyzed to understand auto-closure policies. Where to get Inferred from the sc_req_item state field being updated to a final closed state, such as 'Closed Complete'. This is logged in the sys_audit table. Capture Identify timestamp when sc_req_item.state changes to 'Closed Complete'. Event type inferred
	Service Request Created	This activity marks the beginning of the service request lifecycle, logged when a user submits a request through the service catalog. The system captures this as the creation event of a new record in the sc_req_item (Requested Item) table.
Why it matters This is the primary start event for the process. It is essential for calculating the overall cycle time and analyzing request volumes and submission patterns. Where to get This is an explicit event captured from the creation timestamp (sys_created_on field) of the record in the sc_req_item table. Capture Use the sys_created_on timestamp from the sc_req_item record. Event type explicit
	Service Request Resolved	This activity indicates that the fulfillment agent has completed the work and provided a solution. It is captured when the request's state is updated to 'Resolved' or a similar status.
Why it matters This is a critical milestone that typically stops the SLA clock. It marks the end of active fulfillment work and is a key component of the total resolution time calculation. Where to get Inferred from the sc_req_item state field being updated to 'Resolved' or a similar terminal state before final closure. The change is tracked in the sys_audit table. Capture Identify timestamp when sc_req_item.state changes to 'Resolved'. Event type inferred
	Approval Requested	Represents the point where a service request is submitted for approval from a manager or another designated approver. This is typically inferred when the request's state changes to 'Pending Approval' or a similar status.
Why it matters Tracking approvals helps identify bottlenecks in the approval process and measures the time requests wait for authorization before fulfillment can begin. Where to get Inferred from the sc_req_item state field changing to a pending approval value, or by the creation of a corresponding record in the sysapproval_approver table. Changes are logged in the sys_audit table. Capture Identify timestamp when sc_req_item.state changes to 'Pending Approval'. Event type inferred
	External Vendor Engaged	Represents the handoff of a service request or one of its tasks to an external third-party vendor for fulfillment. This can be inferred from assignment to a vendor-specific group or a flag on the request.
Why it matters This activity enables analysis of vendor performance and its impact on the overall request lifecycle, which is crucial for the 'External Vendor Engagement Cycle' dashboard. Where to get This is typically inferred. It could be based on the assignment_group being set to a vendor's group or a specific flag field being set on the sc_req_item or sc_task record. Capture Identify change of assignment_group to a known vendor group. Event type inferred
	Fulfillment Task Created	Represents the creation of a specific work item or task required to fulfill the service request. This is an explicit event logged when a new record is created in the Catalog Task table.
Why it matters For complex requests, analyzing the creation and completion of individual tasks provides a more granular view of the fulfillment process and where delays occur. Where to get This is an explicit event captured from the creation timestamp (sys_created_on field) of a record in the sc_task table that links to the sc_req_item. Capture Use the sys_created_on timestamp from sc_task records. Event type explicit
	Information Provided by User	This activity marks the point when the requestor has supplied the needed information. It is inferred when the request moves out of an 'Awaiting User Info' state back into an active state like 'Work in Progress'.
Why it matters Paired with 'Information Requested from User', this activity allows for precise measurement of user-induced delays and helps assess the efficiency of the communication process. Where to get Inferred from the sc_req_item state field changing from an 'awaiting information' status to an active status. This is often triggered by the user adding a comment or replying to an email. Capture Identify timestamp when state changes from 'Awaiting User Info' to 'Work in Progress'. Event type inferred
	Request Assigned to Group	Indicates that the service request has been assigned to a specific fulfillment team or group. This event is inferred by detecting a change in the assignment group field on the request item or its associated tasks.
Why it matters Tracking group assignments helps analyze workload distribution across teams and identify delays before a request is routed to the correct fulfillers. Where to get Inferred from a change to the assignment_group field on the sc_req_item or sc_task table. The change history is logged in the sys_audit table. Capture Track changes to the assignment_group field in sys_audit. Event type inferred
	Request Cancelled	This activity serves as a terminal state for requests that are cancelled before completion, either by the user or an agent. This is captured when the request state is set to 'Cancelled' or 'Closed Cancelled'.
Why it matters This is a key unsuccessful end event. Analyzing why requests are cancelled can provide insights into user needs, process inefficiencies, or changing business priorities. Where to get Inferred from the sc_req_item state field being updated to a final cancelled state, like 'Closed Cancelled'. The change is logged in the sys_audit table. Capture Identify timestamp when sc_req_item.state changes to 'Cancelled'. Event type inferred
	Request Rejected	This activity represents the outcome where a request is formally rejected during the approval phase. It's an alternative path to closure and is captured when an approver marks the request as 'rejected'.
Why it matters Tracking rejections helps identify invalid or misdirected requests, issues with the request submission process, and serves as an important exception path for analysis. Where to get Inferred from the state field of the related sysapproval_approver record changing to 'rejected'. This typically sets the parent sc_req_item to a closed, incomplete state. Capture Identify timestamp when sysapproval_approver.state becomes 'rejected'. Event type inferred
	Request Reopened	This activity captures instances where a request that was previously marked as resolved is moved back into an open state. This is inferred from a state change from 'Resolved' back to 'Work in Progress' or similar.
Why it matters This is a direct measure of rework and is critical for calculating the 'First-Pass Resolution Rate' KPI. High numbers indicate poor solution quality or incomplete resolution. Where to get Inferred from a change in the sc_req_item state field, moving from a resolved or closed state back to an open, in-progress state. This change is logged in sys_audit. Capture Detect state change from 'Resolved' to 'Work in Progress' in sys_audit. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from ServiceNow

Steps

Understand the Multi-Export Approach: Due to the nature of ServiceNow's data model, a single export cannot capture every required event. You must perform several exports from different tables and then combine the data externally. The primary tables are Requested Item (sc_req_item), Approval (sysapproval_approver), Catalog Task (sc_task), and Audit (sys_audit).
Export 1: Core Service Request Data: Navigate to the Requested Item table by typing sc_req_item.list in the filter navigator. Apply a filter for the desired date range, for example, [Created] [on] [Last 6 months]. Add columns such as Number, Sys Created On, Resolved, Closed, State, Assignment group, Assigned to, Priority, and Made SLA. Right-click any column header, choose Export, and select CSV or XLSX.
Export 2: Approval Decisions: Navigate to the Approval table by typing sysapproval_approver.list. Filter the list to show only records related to service requests: [Source table] [is] [sc_req_item] AND [Created] [on] [Last 6 months]. Add columns like Approving.Number, State, Sys Created On, and Sys Updated On. Export the filtered list.
Export 3: Fulfillment Task Creation: Navigate to the Catalog Task table by typing sc_task.list. Filter the list to link back to the requests from your chosen timeframe, for example, [Request Item.Created] [on] [Last 6 months]. Add columns Request Item.Number, Sys Created On, State, Assignment group, and Assigned to. Export the data.
Export 4: Detailed Activity History: Navigate to the Audit table using sys_audit.list. This table contains historical field changes. Create a filter for [Table name] [is] [sc_req_item] AND [Created] [on] [Last 6 months] AND [Field name] [is one of] [state, assignment_group, assigned_to]. Add columns Document key, Field name, Old value, New value, and Sys Created On. Export this data. Note that access to this table may require elevated permissions.
Combine and Transform Data: Use a tool like Microsoft Excel, Python with pandas, or a dedicated data preparation tool to merge the four exported files. Use the Service Request Number or Sys ID as the common key to join the data.
Create the Event Log Structure: In your combined file, create the required columns: ServiceRequestID, ActivityName, and EventTime.
Map Raw Data to Activities: Create a new row for each distinct activity. For example:
- For Service Request Created, use the Sys Created On from the sc_req_item export.
- For Request Approved, use the Sys Updated On from the sysapproval_approver export where the State changed to 'approved'.
- For Request Assigned to Group, find the row in the sys_audit export where Field name is assignment_group and use the Sys Created On from that audit record as the EventTime.
Populate Attribute Columns: Fill in the AssignedTo, AssignmentGroup, Priority, State, Category, and MadeSLA attributes for each activity row. The values should reflect the state of the request at the time of the event.
Add Metadata Columns: Add SourceSystem with a static value like 'ServiceNow' and LastDataUpdate with the timestamp of when you performed the extraction.
Finalize and Export: Save the final transformed and combined data as a single CSV file, ensuring the column headers match the requirements for import.

Configuration

Target Tables: The extraction requires data from multiple tables:
- sc_req_item: Contains the primary service request (Requested Item) records.
- sysapproval_approver: Stores approval records related to requests.
- sc_task: Holds the individual fulfillment tasks generated for a request.
- sys_audit: Provides a detailed history of field changes, essential for tracking assignments and state transitions.
Date Range Filtering: It is critical to apply a consistent date range filter, such as Created on Last 6 months, across all exports to ensure data integrity. A period of 3 to 6 months is recommended for a balance of volume and insight.
Key Filters: Beyond the date range, use filters like Source table is sc_req_item on the approval table and Table name is sc_req_item on the audit table to isolate relevant records.
Essential Columns: Ensure you export key identifiers like Number and Sys ID (document key in audit) to join the datasets. Timestamps like Sys Created On, Sys Updated On, Resolved, and Closed are fundamental for creating the event log.
Prerequisites: A ServiceNow user account with at least an itil role is needed to access most of the required tables. Exporting from the sys_audit table may require admin or a specialized role due to its size and sensitivity.

a Sample Query config

This method uses the ServiceNow user interface for filtering and exporting, so there is no single script. The configuration consists of setting filters and choosing columns for multiple list views.

**Configuration for Export 1: Requested Items**
*   **Table**: `sc_req_item`
*   **Filter Conditions**:
    1. `[Created] [on] [Last 6 months]`
    2. `[Active] [is one of] [true, false]` (Or adjust based on process scope)
*   **Columns to Add**: `Number`, `Sys ID`, `Sys Created On`, `Resolved`, `Closed`, `State`, `Stage`, `Assignment group`, `Assigned to`, `Priority`, `Category`, `Made SLA`

**Configuration for Export 2: Approvals**
*   **Table**: `sysapproval_approver`
*   **Filter Conditions**:
    1. `[Source table] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
*   **Columns to Add**: `Approving`, `Approving.Number`, `State`, `Sys Created On`, `Sys Updated On`

**Configuration for Export 3: Catalog Tasks**
*   **Table**: `sc_task`
*   **Filter Conditions**:
    1. `[Request Item.Created] [on] [Last 6 months]`
*   **Columns to Add**: `Request Item`, `Request Item.Number`, `Sys Created On`, `Sys Updated On`, `State`, `Assignment group`, `Assigned to`

**Configuration for Export 4: Audit History**
*   **Table**: `sys_audit`
*   **Filter Conditions**:
    1. `[Table name] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
    3. `[Field name] [is one of] [state, assignment_group, assigned_to]`
*   **Columns to Add**: `Document key`, `Table name`, `Field name`, `Old value`, `New value`, `Sys Created On`

Steps

Prepare Python Environment: Ensure you have Python 3.6 or newer installed. Install the necessary libraries using pip: pip install requests pandas.
Configure Script Parameters: Open the Python script in an editor. Locate the configuration section at the top of the script. Enter your ServiceNow instance URL (e.g., https://your-instance.service-now.com), a username, and a password for a service account with appropriate read permissions on the required tables.
Set Extraction Date Range: Define the start and end dates for the data extraction by modifying the start_date and end_date variables. It is recommended to start with a smaller date range, for example 3 months, to test the script and verify performance.
Review Table and Field Names: The script uses standard ServiceNow table names like sc_req_item, sys_audit, and sc_task. Verify these table and field names match your ServiceNow configuration. Adjust them in the script if your instance uses custom tables or fields.
Execute the Python Script: Run the script from your command line or terminal using the command: python your_script_name.py. The script will connect to the ServiceNow API, fetch data for each specified activity, and display progress messages in the console.
Handle API Pagination: The script includes a function to handle pagination automatically. It will make multiple API calls if the number of records exceeds the page limit (sysparm_limit) until all data within the specified date range is retrieved.
Transform and Combine Data: The script processes the raw JSON response from the API for each activity type. It extracts the required fields, maps them to the event log schema (ServiceRequestID, ActivityName, EventTime, etc.), and combines them into a single, unified dataset.
Generate the Event Log File: Once the script completes, it will save the final event log as a CSV file named servicenow_servicerequest_eventlog.csv in the same directory where the script was run.
Prepare for Upload: Open the generated CSV file in a spreadsheet program to review the data for completeness and correctness. Ensure the column headers match the required ProcessMind schema before uploading.

Configuration

ServiceNow Instance URL: The base URL for your ServiceNow instance (e.g., https://your-instance.service-now.com).
Authentication: A service account username and password with read access to the sc_req_item, sys_audit, sysapproval_approver, and sc_task tables is required.
Date Range: Set the start_date and end_date variables in the script to define the time window for the extraction. A period of 3-6 months is recommended for initial analysis.
Page Limit (sysparm_limit): The script sets a limit for the number of records returned per API call. The default is 1000, which is a safe value for most instances. This can be adjusted based on system performance and API rate limits.
Query Filters (sysparm_query): The script uses date filters (sys_created_on>=...) to limit the data pull. You can add more filters to the query string, such as filtering by a specific catalog item or assignment group, to reduce the data volume (e.g., active=true^category=hardware).
Display Values: The parameter sysparm_display_value=true is used to retrieve human-readable names for reference fields instead of internal sys_id values. This is critical for attributes like AssignmentGroup and AssignedTo.

a Sample Query python

import requests
import pandas as pd
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
SN_INSTANCE = class="hl-string">'https://[your-instance].service-now.com'
SN_USER = class="hl-string">'[your-username]'
SN_PASSWORD = class="hl-string">'[your-password]'

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD)
start_date = class="hl-string">'[YYYY-MM-DD]'
end_date = class="hl-string">'[YYYY-MM-DD]'

class=class="hl-string">"hl-comment"># --- End Configuration ---

def query_servicenow_table(table, query, fields):
    class="hl-string">"""Queries a ServiceNow table with pagination."""
    all_records = []
    offset = 0
    limit = 1000
    
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    url = fclass="hl-string">"{SN_INSTANCE}/api/now/table/{table}"
    
    while True:
        params = {
            class="hl-string">'sysparm_query': query,
            class="hl-string">'sysparm_fields': class="hl-string">','.join(fields),
            class="hl-string">'sysparm_limit': limit,
            class="hl-string">'sysparm_offset': offset,
            class="hl-string">'sysparm_display_value': class="hl-string">'true',
            class="hl-string">'sysparm_exclude_reference_link': class="hl-string">'true'
        }
        
        print(fclass="hl-string">"Querying {table} with offset {offset}...")
        response = requests.get(url, auth=(SN_USER, SN_PASSWORD), headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
        
        records = response.json().get(class="hl-string">'result', [])
        if not records:
            break
        all_records.extend(records)
        offset += limit
        
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    all_events = []
    source_system = class="hl-string">'ServiceNow'
    last_data_update = datetime.datetime.now().isoformat()

    class=class="hl-string">"hl-comment"># Define common attributes to fetch for context
    context_fields = [class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state', class="hl-string">'cat_item.category', class="hl-string">'made_sla']

    class=class="hl-string">"hl-comment"># 1. Service Request Created
    query = fclass="hl-string">'sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    fields = [class="hl-string">'sys_created_on'] + context_fields
    req_items = query_servicenow_table(class="hl-string">'sc_req_item', query, fields)
    for item in req_items:
        all_events.append({
            class="hl-string">'ServiceRequestID': item[class="hl-string">'number'],
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': item[class="hl-string">'sys_created_on'],
            class="hl-string">'AssignedTo': item.get(class="hl-string">'assigned_to'),
            class="hl-string">'AssignmentGroup': item.get(class="hl-string">'assignment_group'),
            class="hl-string">'Priority': item.get(class="hl-string">'priority'),
            class="hl-string">'State': item.get(class="hl-string">'state'),
            class="hl-string">'Category': item.get(class="hl-string">'cat_item.category'),
            class="hl-string">'MadeSLA': item.get(class="hl-string">'made_sla')
        })

    class=class="hl-string">"hl-comment"># Get a list of relevant document keys (sys_id of sc_req_item)
    doc_keys_query = fclass="hl-string">'tablename=sc_req_item^sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    audit_records = query_servicenow_table(class="hl-string">'sys_audit', doc_keys_query, [class="hl-string">'documentkey'])
    relevant_doc_keys = list(set([rec[class="hl-string">'documentkey'] for rec in audit_records]))
    
    class=class="hl-string">"hl-comment"># Query audit and other tables in batches to avoid long URLs
    batch_size = 50
    for i in range(0, len(relevant_doc_keys), batch_size):
        key_batch = relevant_doc_keys[i:i+batch_size]
        key_batch_str = class="hl-string">','.join(key_batch)

        class=class="hl-string">"hl-comment"># 2-14. Activities from sys_audit, sysapproval_approver, sc_task
        class=class="hl-string">"hl-comment"># Fetch sc_req_item details for context
        ritm_context = {ritm[class="hl-string">'sys_id']: ritm for ritm in query_servicenow_table(class="hl-string">'sc_req_item', fclass="hl-string">'sys_idIN{key_batch_str}', [class="hl-string">'sys_id'] + context_fields)}

        class=class="hl-string">"hl-comment"># Activities based on state changes and field updates from sys_audit
        audit_query = fclass="hl-string">'documentkeyIN{key_batch_str}^fieldnameINassignment_group,assigned_to,state'
        audit_log = query_servicenow_table(class="hl-string">'sys_audit', audit_query, [class="hl-string">'documentkey', class="hl-string">'sys_created_on', class="hl-string">'fieldname', class="hl-string">'newvalue', class="hl-string">'oldvalue'])
        for log in audit_log:
            context = ritm_context.get(log[class="hl-string">'documentkey'], {})
            if not context:
                continue

            event = {
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'EventTime': log[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'),
                class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'),
                class="hl-string">'Priority': context.get(class="hl-string">'priority'),
                class="hl-string">'State': context.get(class="hl-string">'state'),
                class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'),
                class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla'),
            }
            activity = None
            class=class="hl-string">"hl-comment"># Map audit entries to activities
            if log[class="hl-string">'fieldname'] == class="hl-string">'assignment_group' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Group'
                event[class="hl-string">'AssignmentGroup'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'assigned_to' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Agent'
                event[class="hl-string">'AssignedTo'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'state':
                class=class="hl-string">"hl-comment"># Define state mappings, may need customization
                state_map = {
                    class="hl-string">'Awaiting User Info': class="hl-string">'Information Requested from User',
                    class="hl-string">'Resolved': class="hl-string">'Service Request Resolved',
                    class="hl-string">'Closed Complete': class="hl-string">'Service Request Closed',
                    class="hl-string">'Closed Cancelled': class="hl-string">'Request Cancelled'
                }
                if log[class="hl-string">'newvalue'] in state_map:
                    activity = state_map[log[class="hl-string">'newvalue']]
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Awaiting User Info':
                    activity = class="hl-string">'Information Provided by User'
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Resolved':
                    activity = class="hl-string">'Request Reopened'
                class=class="hl-string">"hl-comment"># For class="hl-string">'Approval Requested', class="hl-string">'External Vendor Engaged' - more complex logic might be needed
                class=class="hl-string">"hl-comment"># This is a common inference. Adjust if you have a specific state.
                if log[class="hl-string">'newvalue'] == class="hl-string">'Pending Approval':
                     activity = class="hl-string">'Approval Requested'

            if activity:
                event[class="hl-string">'ActivityName'] = activity
                all_events.append(event)

        class=class="hl-string">"hl-comment"># Approval Activities
        approval_query = fclass="hl-string">'sysapprovalIN{key_batch_str}'
        approvals = query_servicenow_table(class="hl-string">'sysapproval_approver', approval_query, [class="hl-string">'sysapproval', class="hl-string">'sys_updated_on', class="hl-string">'state'])
        for appr in approvals:
            context = ritm_context.get(appr[class="hl-string">'sysapproval'], {})
            if not context: continue
            activity = None
            if appr[class="hl-string">'state'] == class="hl-string">'approved':
                activity = class="hl-string">'Request Approved'
            elif appr[class="hl-string">'state'] == class="hl-string">'rejected':
                activity = class="hl-string">'Request Rejected'
            if activity:
                all_events.append({
                    class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': appr[class="hl-string">'sys_updated_on'],
                    class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
                })

        class=class="hl-string">"hl-comment"># Fulfillment Task Creation
        task_query = fclass="hl-string">'request_itemIN{key_batch_str}'
        tasks = query_servicenow_table(class="hl-string">'sc_task', task_query, [class="hl-string">'request_item', class="hl-string">'sys_created_on', class="hl-string">'number'])
        for task in tasks:
            context = ritm_context.get(task[class="hl-string">'request_item'], {})
            if not context: continue
            all_events.append({
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'ActivityName': fclass="hl-string">'Fulfillment Task Created - {task["number"]}',
                class="hl-string">'EventTime': task[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
            })

    class=class="hl-string">"hl-comment"># Post-processing and saving
    if not all_events:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = source_system
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to match schema
    final_cols = [class="hl-string">'ServiceRequestID', 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">'State', class="hl-string">'Category', class="hl-string">'MadeSLA']
    df = df[final_cols]
    
    df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], inplace=True)
    df.to_csv(class="hl-string">'servicenow_servicerequest_eventlog.csv', index=False)
    print(class="hl-string">"Extraction complete. File saved to servicenow_servicerequest_eventlog.csv")

if __name__ == class="hl-string">'__main__':
    main()

Steps

Set Up ServiceNow API User: Create a dedicated user in your ServiceNow instance for this integration. Assign this user the rest_service and itil roles. Ensure the user has read access permissions (ACLs) to the following tables: Requested Item (sc_req_item), Catalog Task (sc_task), Approval (sysapproval_approver), and Audit (sys_audit).
Prepare Your Development Environment: Install Node.js on the machine you will use for the extraction. Then, initialize a new Node.js project and install the axios library for making HTTP requests and fast-csv for writing the output file by running npm install axios fast-csv in your terminal.
Configure the Extraction Script: Copy the provided JavaScript code into a file, for example, extract.js. Fill in the placeholder values at the top of the script for your ServiceNow instance URL, API username, and password.
Define Date Range and Filters: Modify the startDate and endDate variables in the script to define the time window for the extraction. You can also add more filters to the sysparm_query strings for each activity to narrow down the scope, such as filtering by a specific catalog item or assignment group.
Understand the API Calls: The script is designed to make separate API calls for each of the 14 required activities. Events like creation are queried directly from their source tables (sc_req_item, sc_task), while status changes and assignments are captured by querying the sys_audit table for specific field updates.
Execute the Script: Run the script from your terminal using the command node extract.js. The script will connect to the ServiceNow Table API, fetch data for each activity, and handle pagination automatically.
Process the Data: As data is retrieved, the script transforms the JSON response from ServiceNow into a standardized event log format, mapping fields to columns like ServiceRequestID, ActivityName, and EventTime.
Combine and Consolidate Results: The script gathers the results from all individual API calls into a single, unified array representing the complete event log.
Generate the Output File: Once all data is fetched and processed, the script uses the fast-csv library to write the consolidated event log to a file named servicenow_event_log.csv in the same directory.
Prepare for Upload: The generated CSV file is structured with the required columns for process mining. No further formatting is needed before uploading it to the ProcessMind platform.

Configuration

ServiceNow Instance URL: The base URL of your ServiceNow environment, for example, https://your-instance.service-now.com.
API Credentials: A valid username and password for a ServiceNow user with the necessary read permissions and roles (rest_service, itil).
Date Range: We recommend extracting data for a period of 3 to 6 months to ensure a representative dataset. This is configured in the script using startDate and endDate variables, which are applied to the appropriate timestamp fields in the API queries.
sysparm_query: This is the primary URL parameter used to filter records. The script uses it extensively to isolate specific events, such as records created within a date range or audit records showing a state change from 'Resolved' to 'Work in Progress'.
sysparm_fields: This parameter specifies which columns to return from the API call. Using it significantly improves performance by reducing the amount of data transferred. The script pre-configures the necessary fields for each query.
Pagination Limit (sysparm_limit): The script is configured to fetch records in batches of 1000. This value can be adjusted, but staying below the ServiceNow maximum (typically 10,000) is recommended to ensure stability.

a Sample Query javascript

const axios = require('axios');
const fs = require('fs');
const { format, writeToStream } = require('@fast-csv/format');

// --- Configuration ---
const SN_INSTANCE = 'https://YOUR_INSTANCE.service-now.com';
const SN_USER = 'YOUR_API_USER';
const SN_PASSWORD = 'YOUR_API_PASSWORD';
const BATCH_SIZE = 1000;

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

const auth = { username: SN_USER, password: SN_PASSWORD };

// --- Helper Function for Paginated API Calls ---
async function fetchAllRecords(table, query, fields, processFunction) {
    let offset = 0;
    let hasMore = true;
    let allEvents = [];

    console.log(`Starting fetch for table: ${table}`);

    while (hasMore) {
        try {
            const response = await axios.get(`${SN_INSTANCE}/api/now/table/${table}`, {
                auth,
                params: {
                    sysparm_query: query,
                    sysparm_fields: fields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset,
                    sysparm_display_value: 'true', // Get display values for reference fields
                    sysparm_exclude_reference_link: true
                }
            });

            const records = response.data.result;
            if (records.length > 0) {
                console.log(`Fetched ${records.length} records from ${table} with offset ${offset}`);
                const processedEvents = records.map(processFunction);
                allEvents.push(...processedEvents);
                offset += BATCH_SIZE;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching data from ${table}:`, error.response ? error.response.statusText : error.message);
            hasMore = false; // Stop on error
        }
    }
    return allEvents;
}

// --- Main Extraction Logic ---
async function extractServiceRequestData() {
    let finalEventLog = [];
    const now = new Date().toISOString();

    // 1. Service Request Created
    const createdEvents = await fetchAllRecords(
        'sc_req_item',
        `sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'number,sys_created_on,assigned_to,assignment_group,priority,state,cat_item.category,made_sla',
        (r) => ({
            ServiceRequestID: r.number,
            ActivityName: 'Service Request Created',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: r.assigned_to,
            AssignmentGroup: r.assignment_group,
            Priority: r.priority,
            State: r.state,
            Category: r['cat_item.category'],
            MadeSLA: r.made_sla
        })
    );
    finalEventLog.push(...createdEvents);

    // 2. Approval Requested
    const approvalRequestedEvents = await fetchAllRecords(
        'sysapproval_approver',
        `sysapproval.sys_class_name=sc_req_item^state=requested^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'sysapproval,sys_created_on',
        (r) => ({
            ServiceRequestID: r.sysapproval,
            ActivityName: 'Approval Requested',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Pending Approval', Category: null, MadeSLA: null
        })
    );
    finalEventLog.push(...approvalRequestedEvents);

    // Function to process audit records
    const processAuditRecord = (activityName) => (r) => ({
        ServiceRequestID: r['documentkey.number'],
        ActivityName: activityName,
        EventTime: r.sys_created_on,
        SourceSystem: 'ServiceNow',
        LastDataUpdate: now,
        AssignedTo: activityName === 'Request Assigned to Agent' ? r.newvalue : null,
        AssignmentGroup: activityName === 'Request Assigned to Group' ? r.newvalue : null,
        Priority: null, 
        State: ['Service Request Resolved', 'Service Request Closed', 'Request Cancelled', 'Request Reopened', 'Information Requested from User', 'Information Provided by User'].includes(activityName) ? r.newvalue : null,
        Category: null, 
        MadeSLA: null
    });
    
    // 3. Request Approved
    const approvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=approved^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Approved', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Approved', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...approvedEvents);

    // 4. Request Assigned to Group
    const assignedGroupEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Group')
    );
    finalEventLog.push(...assignedGroupEvents);

    // 5. Request Assigned to Agent
    const assignedAgentEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assigned_to^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Agent')
    );
    finalEventLog.push(...assignedAgentEvents);

    // 6. Fulfillment Task Created
    const taskCreatedEvents = await fetchAllRecords(
        'sc_task',
        `request_item.sys_class_name=sc_req_item^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'request_item.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['request_item.number'], ActivityName: 'Fulfillment Task Created', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: null, Category: null, MadeSLA: null })
    );
    finalEventLog.push(...taskCreatedEvents);

    // 7. Information Requested from User
    const infoRequestedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Requested from User')
    );
    finalEventLog.push(...infoRequestedEvents);

    // 8. Information Provided by User
    const infoProvidedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Provided by User')
    );
    finalEventLog.push(...infoProvidedEvents);

    // 9. External Vendor Engaged (Note: requires a specific vendor group name)
    const vendorEngagedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^newvalue=[Your Vendor Assignment Group Name]^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('External Vendor Engaged')
    );
    finalEventLog.push(...vendorEngagedEvents);

    // 10. Request Reopened
    const reopenedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Resolved^newvalue=Work in Progress^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Reopened')
    );
    finalEventLog.push(...reopenedEvents);

    // 11. Service Request Resolved
    const resolvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Resolved^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Resolved')
    );
    finalEventLog.push(...resolvedEvents);

    // 12. Service Request Closed
    const closedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalueINClosed Complete,Closed Incomplete,Closed Skipped^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Closed')
    );
    finalEventLog.push(...closedEvents);

    // 13. Request Rejected
    const rejectedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=rejected^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Rejected', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Rejected', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...rejectedEvents);

    // 14. Request Cancelled
    const cancelledEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Cancelled^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Cancelled')
    );
    finalEventLog.push(...cancelledEvents);

    // --- Write to CSV ---
    const csvStream = format({ headers: true });
    const writableStream = fs.createWriteStream('servicenow_event_log.csv');

    writableStream.on('finish', () => {
        console.log('CSV file written successfully.');
    });

    csvStream.pipe(writableStream);
    finalEventLog.sort((a, b) => new Date(a.EventTime) - new Date(b.EventTime)); // Sort events chronologically
    finalEventLog.forEach(row => csvStream.write(row));
    csvStream.end();
}

extractServiceRequestData();

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

ServiceNow Report and List Export to CSV/XLSX

Steps

Configuration

a Sample Query config

Python Script using Requests for Table API Extraction

Steps

Configuration

a Sample Query python

Data Extraction via ServiceNow REST Table API

Steps

Configuration

a Sample Query javascript

Ready to Get Started?

Transform Service Request Management: Act Now

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

ServiceNow Report and List Export to CSV/XLSX

Steps

Configuration

a Sample Query config

Python Script using Requests for Table API Extraction

Steps

Configuration

a Sample Query python

Data Extraction via ServiceNow REST Table API

Steps

Configuration

a Sample Query javascript

We value your privacy

Ready to Get Started?

Transform Service Request Management: Act Now