> Continuous Process Improvement > Service Request Management > Ivanti Service Manager > Data Template

Your Service Request Management Data Template

Ivanti Service Manager

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

Your Service Request Management Data Template

This template provides a comprehensive guide to collecting the essential data required for effective process mining of your service request management. It outlines the crucial attributes to gather, key activities to track, and includes practical guidance on extracting this information from your system. Use this resource to build a robust event log for your analysis.

Recommended attributes for comprehensive analysis
Key activities to track for process discovery
Guidance on data extraction from your source system

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 a comprehensive analysis of your service request management process.

5 Required 10 Recommended 7 Optional

	Name	Description
	Activity Name ActivityName	The name of the event or task that occurred at a specific point in the service request lifecycle.
Description This attribute describes a specific step or status change within the service request process, such as 'Request Submitted for Approval' or 'Service Request Resolved'. Analyzing the sequence and frequency of activities is fundamental to understanding the process flow, identifying bottlenecks, and discovering deviations from the standard procedure. Why it matters It defines the steps in the process map, allowing for the visualization and analysis of the process flow, including identifying rework, bottlenecks, and deviations. Where to get Typically derived from status changes, journal entries, or audit log event descriptions within Ivanti Service Manager. Examples Service Request CreatedRequest ApprovedService Request ResolvedService Request Closed
	Event Time EventTime	The timestamp indicating when a specific activity or event occurred.
Description Event Time, also known as the start time, is the precise date and time that an activity was recorded in the system. This timestamp is critical for sequencing events correctly and forms the basis for all time-based process mining analysis, such as calculating cycle times, waiting times, and activity durations. Why it matters This timestamp is essential for ordering events chronologically and calculating all duration-based metrics, which are key to performance analysis. Where to get Found in audit logs, journal entries (e.g., Journal.CreatedDateTime), or status change records associated with the Service Request. Examples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Service Request ID ServiceRequestID	The unique identifier for each service request.
Description The Service Request ID uniquely identifies each individual service request submitted by a user or system. It serves as the central thread linking all subsequent events, from initial logging to final closure, allowing for a complete, end-to-end analysis of each service request's journey. Why it matters This is the essential case identifier that connects all related activities into a single process instance, enabling end-to-end process analysis. Where to get This is the primary key of the Service Request business object, often found as ServiceReqNumber in the ServiceReq table. Examples SR-0012345SR-0012346SR-0012347
	Last Data Update LastDataUpdate	The timestamp of the most recent data refresh from the source system.
Description This attribute indicates the date and time when the data was last extracted from Ivanti Service Manager. It provides context on the freshness of the data being analyzed, ensuring that users are aware of the time period covered by the analysis and when the next update can be expected. Why it matters Informs users about the timeliness of the data, which is critical for making decisions based on the most current process performance information available. Where to get This value is generated and stamped onto the dataset at the time of data extraction. Examples 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Source System SourceSystem	The system from which the data was extracted.
Description This attribute identifies the origin of the process data. For this view, the value will be constant, indicating that all data comes from Ivanti Service Manager. This is important in environments where data might be merged from multiple systems, ensuring clear data lineage and context. Why it matters It provides crucial context about data provenance, ensuring that analyses are correctly attributed to the specific source system, especially in multi-system environments. Where to get This is typically a static value added during the data extraction process to label the dataset's origin. Examples Ivanti Service Manager
	Assigned Agent AssignedAgent	The individual user or agent assigned to the service request.
Description The Assigned Agent is the specific person responsible for working on the service request. This attribute allows for analysis at the individual level, which is useful for performance management, workload balancing, and identifying training opportunities. Tracking reassignments between agents is key to calculating KPIs like 'Average Reassignments per Request' and understanding process inefficiencies. Why it matters Enables analysis of individual workload, performance, and reassignment patterns, which can indicate issues with training, skill sets, or initial routing. Where to get Typically found in a field like 'Owner' on the Service Request object. This may change with each reassignment and should be tracked in the event log. Examples Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Assigned Team AssignedTeam	The support team or group currently assigned to handle the service request.
Description This attribute identifies the team responsible for actioning the service request at a given point in time. Analyzing handoffs between teams, time spent with each team, and the volume of requests handled by different teams is crucial for understanding workload distribution, identifying bottlenecks, and evaluating team performance. It directly supports dashboards related to SLA adherence and agent workload. Why it matters Tracks responsibility and handoffs, helping to analyze inter-team delays, workload balance, and which teams are bottlenecks in the process. Where to get This information is typically stored in a field like 'OwnerTeam' on the Service Request object or in related assignment records. Examples IT Service DeskNetwork OperationsHR SupportFacilities Management
	Cycle Time CycleTime	The total time from the creation of the service request to its final resolution.
Description Cycle Time is a calculated metric that measures the duration from the first event (Service Request Created) to the resolution event (Service Request Resolved). It is one of the most important key performance indicators for process efficiency. This metric is used extensively in dashboards to track overall performance and identify trends over time. Why it matters This is a primary KPI for measuring end-to-end process efficiency and directly reflects the service experience from the user's point of view. Where to get Calculated by subtracting the creation timestamp from the resolution timestamp for each service request. Examples 25920000060480000086400000
	Event End Time EventEndTime	The timestamp indicating when an activity was completed.
Description The Event End Time marks the completion of an activity. The duration between the Event Time (start) and Event End Time represents the processing time for that specific activity. This is crucial for identifying which steps in the process consume the most time, helping to pinpoint inefficiencies and areas for improvement. Why it matters It enables the calculation of individual activity durations, which is essential for identifying process bottlenecks and long-running tasks. Where to get May not exist as a distinct field. Often, it is the start time of the subsequent activity in the sequence for the same case. Examples 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Priority Priority	The priority level assigned to the service request.
Description Priority indicates the urgency of a service request, typically on a scale like 'Low', 'Medium', 'High', 'Critical'. This attribute is fundamental for evaluating whether the process effectively fast-tracks high-priority requests. Analysis often involves comparing cycle times and SLA adherence across different priority levels to ensure that prioritization rules are working as intended. Why it matters Crucial for assessing the effectiveness of the prioritization strategy and ensuring that high-priority requests are resolved faster than low-priority ones. Where to get A standard field on the Service Request object, usually named 'Priority'. Examples 1 - Critical2 - High3 - Medium4 - Low
	Resolution Timestamp ResolutionDateTime	The date and time when the service request was officially resolved.
Description This is a case-level attribute marking the final timestamp when the service was delivered or the issue was fixed, before the request is formally closed. This timestamp is the primary endpoint for calculating the end-to-end cycle time of a service request. It is a critical component for measuring overall process efficiency and SLA adherence. Why it matters Defines the end point for the core process cycle time calculation, a key performance indicator for service delivery efficiency. Where to get A specific timestamp field on the Service Request object, often named 'ResolvedDateTime' or similar. Examples 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Service Request Status ServiceRequestStatus	The status of the service request at the time of the event.
Description This attribute captures the state of the service request, such as 'Logged', 'In Progress', 'Pending', 'Resolved', or 'Closed'. Status changes often define the activities in the process log. Analyzing the time spent in each status can reveal bottlenecks, for example, if requests spend too long in a 'Pending' state. Why it matters Provides a snapshot of the request's state at any given time, which is essential for calculating time spent in specific states and identifying process stalls. Where to get A standard field on the Service Request object, commonly named 'Status'. Examples LoggedActiveWaiting for CustomerFulfilledClosed
	Service Request Type ServiceRequestType	The classification or category of the service request.
Description This attribute categorizes the service request, for example, 'Hardware Request', 'Software Installation', or 'Password Reset'. It is a critical dimension for analysis, allowing teams to compare process performance, cycle times, and SLA adherence across different types of services. Understanding these differences helps in tailoring process improvements and allocating resources more effectively. Why it matters Segmenting the process by request type allows for targeted analysis, revealing if certain types of requests are more prone to delays, rework, or SLA breaches. Where to get Likely a field on the Service Request business object, often named 'Service' or 'Category'. Consult Ivanti Service Manager documentation for specific field names like 'SvcReqTmplLink_Category'. Examples New Hardware RequestSoftware AccessAccount ModificationInformation Inquiry
	SLA Deadline SLADeadline	The timestamp by which the service request is expected to be resolved.
Description The SLA Deadline is the calculated date and time by which a service request must be resolved to meet its Service Level Agreement. This target is typically determined based on factors like the request's priority and type. Comparing the actual resolution time to this deadline is the basis for measuring SLA adherence. Why it matters It is the benchmark against which actual performance is measured, directly supporting the calculation of SLA adherence rates and identifying at-risk requests. Where to get This is often a calculated field within Ivanti, stored in fields related to the Service Level Agreement or Offering, such as 'ResolutionTargetDateTime'. Examples 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	SLA Status SLAStatus	Indicates whether the service request was resolved within its SLA deadline.
Description This is a derived attribute that flags each service request as 'Met' or 'Breached' based on its resolution time relative to its SLA deadline. It is the foundation for the 'SLA Adherence Performance' dashboard and the 'Service Level Agreement Adherence Rate' KPI. The logic compares the ResolutionDateTime with the SLADeadline for each case. Why it matters Directly measures performance against service commitments, which is critical for assessing service quality and maintaining user trust. Where to get Calculated by comparing the 'ResolutionDateTime' to the 'SLADeadline'. If ResolutionDateTime <= SLADeadline, the status is 'Met'; otherwise, it is 'Breached'. Examples MetBreached
	Assignment Count AssignmentCount	The total number of times a service request was assigned or reassigned.
Description This calculated metric counts the number of assignment-related activities (e.g., 'Assigned to Team', 'Assigned to Agent') for each service request. A high number of reassignments, often called 'ticket ping-pong', indicates inefficiencies in routing, lack of first-contact resolution, or unclear team responsibilities. This attribute is essential for the 'Average Reassignments per Request' KPI. Why it matters Quantifies inefficient handoffs and routing problems. A high count is a strong indicator of prolonged resolution times and user frustration. Where to get Calculated by counting the occurrences of assignment-related activities for each unique ServiceRequestID during data preparation. Examples 12345
	Channel Channel	The method or channel through which the service request was submitted.
Description The channel indicates how the service request was created, for instance, via the Self-Service Portal, Email, Phone, or automatically by another system. Analyzing request volumes and resolution times by channel can provide insights into which channels are most efficient and which may require process improvements or user training. Why it matters Helps in understanding user behavior and channel efficiency, which can inform decisions about service delivery strategy and automation opportunities. Where to get This is often stored in a 'Source' or 'CreatedBy' type of field on the Service Request object. Examples Self ServiceEmailPhoneDirect Input
	Is Rework IsRework	A boolean flag indicating if the service request involved rework activities.
Description This calculated flag is set to true if a service request shows signs of rework, such as being reopened after resolution or having certain activities repeated in a loop. It simplifies the calculation of the 'Service Request Rework Rate' KPI and helps filter for inefficient process instances in dashboards like 'Rework and Reassignment Flows'. Why it matters Helps to easily identify and quantify the volume of requests that require additional, unplanned effort, highlighting quality and efficiency issues. Where to get Derived from the data. The logic can be based on the 'ReopenCount' attribute being greater than zero or by detecting specific activity sequences, like multiple 'Assigned to Agent' events. Examples truefalse
	Reopen Count ReopenCount	The number of times a resolved service request has been reopened.
Description This attribute is a counter that increments each time a service request is moved from a 'Resolved' or 'Closed' state back to an 'Active' state. A high reopen count is a strong indicator of poor first-time resolution quality, incomplete solutions, or recurring issues. It directly supports the 'Service Request Rework Rate' KPI. Why it matters Directly measures rework and is a key indicator of resolution quality. High counts suggest that the initial fix was not effective. Where to get This is typically a counter field on the Service Request object that is incremented by a business rule when the status changes appropriately. It might be named 'ReopenCounter'. Examples 0123
	Requestor Department RequestorDepartment	The business department of the user who submitted the service request.
Description This attribute identifies the department of the employee or system that initiated the service request, such as 'Sales', 'Finance', or 'Human Resources'. It allows for analysis of service quality and demand across different parts of the organization. For example, it can help identify if certain departments experience longer resolution times or submit a higher volume of requests. Why it matters Allows for analysis of service consumption and quality by business unit, helping to identify department-specific issues or trends. Where to get This information is usually retrieved from the requestor's user profile, linked to the Service Request. The field could be 'Department' in the Profile.Employee object. Examples FinanceSalesMarketingInformation Technology
	Resolution Category ResolutionCategory	A classification of the resolution provided for the service request.
Description The Resolution Category provides a structured way to classify how a service request was ultimately resolved. This is often a hierarchical classification (e.g., Category, Subcategory) that helps in root cause analysis and trend reporting. For instance, it can highlight recurring issues or common types of fulfillment actions, which can be used to improve services or create knowledge base articles. Why it matters Provides insights into the nature of resolutions, helping to identify common problems, service improvement opportunities, and automation candidates. Where to get Often stored in categorization fields that are filled out upon resolution, such as 'ResolutionCategory' or a custom closing code field. Examples User Training RequiredSoftware DeployedHardware RepairedAccess Granted
	Vendor Name VendorName	The name of the external vendor involved in resolving the request.
Description This attribute identifies the third-party vendor engaged to assist with or complete a service request. It is essential for the 'External Vendor Activity Duration' dashboard, as it allows for measuring and comparing the performance of different vendors. Tracking this helps in managing vendor relationships and identifying bottlenecks caused by external dependencies. Why it matters Enables analysis of third-party performance and their impact on overall service request resolution times, supporting vendor management. Where to get This could be a field on a task object associated with the service request, or a specific field on the Service Request itself if a vendor is assigned. Examples Dell SupportOracle ConsultingMicrosoft Premiernull

Required Recommended Optional

Service Request Management Activities

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

5 Recommended 9 Optional

	Activity	Description
	Request Assigned to Agent	A specific agent takes ownership of the service request. This activity is typically inferred when the 'Owner' field, which designates the individual agent, is populated or updated for the first time.
Why it matters This marks the end of the initial waiting or queue time. Measuring the duration before this activity helps identify resource allocation issues and supports the Agent Workload dashboard. Where to get Inferred from the population or change of the 'Owner' field in the Service Request record, as seen in the audit history. Capture The first timestamp where the 'Owner' field is populated with an agent's name after creation or team assignment. Event type inferred
	Request Assigned to Team	The service request is assigned to a specific support team for handling. This is captured by observing the population or change of the 'OwnerTeam' field in the Service Request record.
Why it matters This event is crucial for analyzing team-level performance, workload distribution, and inter-team handoff times. It helps identify which teams are bottlenecks in the process. Where to get Tracked by changes in the 'OwnerTeam' field within the Service Request's audit history or journal. Capture An update event to the 'OwnerTeam' field, which is typically logged in an audit trail. Event type explicit
	Service Request Closed	The service request is officially closed, and no further actions can be taken. This often occurs automatically after a set period in the 'Resolved' state, representing the final conclusion of the lifecycle.
Why it matters This activity is the definitive end of the process. The time between 'Resolved' and 'Closed' can highlight delays in confirmation or automated system processes. Where to get Inferred from a change in the 'Status' field of the Service Request record to 'Closed', along with the associated timestamp. Capture Detecting the update of the 'Status' field to 'Closed' from the audit history. Event type inferred
	Service Request Created	This activity marks the beginning of the service request lifecycle when a new request is formally submitted and logged in Ivanti. This event is captured when a new record is created in the Service Request business object, generating a unique Service Request ID.
Why it matters This is the primary start event for the process. Analyzing the time from this point to resolution is fundamental for measuring overall cycle time and process efficiency. Where to get This is captured from the creation timestamp of the Service Request record (e.g., CreatedDateTime field in the ServiceReq business object). Capture The record creation event in the ServiceReq table, identified by its creation timestamp. Event type explicit
	Service Request Resolved	The service request is considered resolved, and the solution has been delivered to the user. This is a primary milestone captured by a status change to 'Resolved', often triggering an SLA clock to stop.
Why it matters This is a critical end-point for measuring resolution time and SLA adherence. The duration from creation to this activity is a core KPI for process performance. Where to get Inferred from a change in the 'Status' field of the Service Request record to 'Resolved', along with the associated timestamp. Capture Detecting the update of the 'Status' field to 'Resolved' from the audit history. Event type inferred
	External Vendor Engaged	The service request fulfillment has been handed off to an external vendor or third party. This is typically captured by a status change to 'Waiting for 3rd Party' or a similar state.
Why it matters This activity is essential for measuring vendor performance and its impact on the overall cycle time. It allows for analysis of vendor-related delays and supports the External Vendor Activity Duration dashboard. Where to get Inferred from a status change in the Service Request record to a status like 'Waiting for 3rd Party' or 'Pending Vendor'. Capture Detecting a change in the 'Status' field to a designated 'waiting on vendor' state. Event type inferred
	Information Provided by User	The requestor has provided the necessary information, allowing the agent to resume work. This is captured when the request moves out of a 'Waiting for Customer' status back to an active state.
Why it matters This event closes the loop on information requests. The time between requesting and receiving information is a critical component of process delays and rework loops. Where to get Inferred when the 'Status' field of the Service Request changes from a 'Waiting for Customer' state to an active one, like 'Active' or 'In Progress'. Capture Detecting a status change from a 'waiting on user' state to an active state. Event type inferred
	Information Requested from User	The assigned agent requires more information from the requestor to proceed with fulfillment. This is captured when the request status is updated to a state like 'Waiting for Customer'.
Why it matters This activity highlights delays caused by incomplete initial information. Tracking its frequency and duration is key for the Information Request Impact Analysis and identifying areas for process improvement. Where to get Inferred from a status change in the Service Request record to a status such as 'Waiting for Customer' or 'Pending'. Capture Detecting a change in the 'Status' field to a designated 'waiting on user' state. Event type inferred
	Priority Changed	The priority of the service request has been updated after its initial creation. This event is captured from the audit log or history that tracks field-level changes.
Why it matters Tracking priority changes is vital for the Prioritization Effectiveness Overview. It helps determine if escalations are managed correctly and if initial prioritization is accurate. Where to get This is an explicit event captured from the audit history of the Service Request record, which logs changes to the 'Priority' field. Capture An update event to the 'Priority' field recorded in the system's audit trail. Event type explicit
	Request Approved	The service request has received all necessary approvals and can now proceed to fulfillment. This event is captured when the approval workflow concludes successfully, changing the request's status.
Why it matters This activity marks a key milestone, signaling the end of the approval phase and the start of fulfillment. It allows for measuring the efficiency of the approval process itself. Where to get Inferred from a status change from 'Waiting for Approval' to 'Approved' or 'Fulfilled'. This may also be an explicit event logged in the FRS_Approval business object. Capture A change in the 'Status' field of the Service Request record from an approval state to an active one. Event type inferred
	Request Submitted for Approval	The service request has been submitted for necessary approvals before it can be fulfilled. This is typically inferred when the request status changes to 'Submitted' or 'Pending Approval', often triggering an approval workflow.
Why it matters Tracking this activity helps identify delays in the approval phase. Long waits here can be a significant bottleneck, impacting overall resolution times and user satisfaction. Where to get Inferred from a status change on the Service Request record, likely to a status like 'Submitted' or 'Waiting for Approval'. This can also be sourced from the FRS_Approval or FRS_ApprovalVoteTracking business objects. Capture A change in the 'Status' field of the Service Request record to an approval-pending state. Event type inferred
	Service Request Cancelled	The service request has been cancelled by the user or an agent before resolution. This is an alternative end state captured by a status change to 'Cancelled' or 'Withdrawn'.
Why it matters This represents a non-standard process termination. Analyzing why requests are cancelled can reveal issues with the request process itself or changing user needs. Where to get Inferred from a change in the 'Status' field of the Service Request record to 'Cancelled'. Capture Detecting the update of the 'Status' field to 'Cancelled' from the audit history. Event type inferred
	Service Request Fulfilled	All tasks required to fulfill the service request have been completed by the agent or system. This is captured by a status change to 'Fulfilled', which often precedes the final 'Resolved' status.
Why it matters This milestone marks the completion of the technical or procedural work. It is a key point for measuring the active handling time before final confirmation and closure. Where to get Inferred from a change in the 'Status' field of the Service Request record to 'Fulfilled'. Capture A change in the 'Status' field to 'Fulfilled' detected from the record's history. Event type inferred
	Service Request Reopened	A previously resolved service request has been reactivated because the issue persists or the solution was unsatisfactory. This is captured when the status moves from 'Resolved' back to an active state like 'Active' or 'Assigned'.
Why it matters This activity is a direct indicator of rework and poor first-time resolution quality. Analyzing reopen events helps identify process weaknesses and improve the Service Request Rework Rate KPI. Where to get Inferred from the audit history when the 'Status' field changes from 'Resolved' or 'Closed' to an active status. Capture A status change from a terminal state ('Resolved', 'Closed') to an open state ('Active', 'Assigned'). Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Ivanti Service Manager

Steps

Log into Ivanti Service Manager with a role that has read access to Service Requests and their audit history.
Navigate to the Service Request workspace from the main navigation panel.
This process requires two separate data exports that will be combined externally. The first captures the creation event and core attributes, and the second captures the detailed history of changes.
First Export (Creation Events): Create a new Saved Search on the ServiceReq business object. Set a filter for CreatedDateTime to select service requests created within your desired analysis period, for example, the last six months.
Configure the columns for the Creation search to include RecId, ServiceReqNumber (for ServiceRequestID), CreatedDateTime (for EventTime), SvcReqTmplLink_Category (for ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime, and TargetDateTime (for SLADeadline).
Run the search and use the grid's export function, typically an icon resembling a disk or arrow, to export the data to a CSV file. Name it ServiceRequests.csv.
Second Export (Audit History Events): Create a new Saved Search, this time on the FRS_data_audit_history business object, which logs field changes.
Filter this search to only include changes related to Service Requests. Add a filter where ParentObjectType equals 'ServiceReq'. Also, add a filter on AuditDate for the same analysis period you used previously.
Configure the columns for the Audit search to include ParentLink_RecID (to link back to the service request), FieldName, OldValue, NewValue, and AuditDate (for EventTime). Export this data to a second CSV file named AuditHistory.csv.
Data Transformation and Combination: The exported CSV files must be combined and reshaped into a single event log. Use a data preparation tool like Power Query in Excel, Python, or a database tool to perform the following steps:
- Load both ServiceRequests.csv and AuditHistory.csv.
- Use the ServiceRequests.csv file to generate the 'Service Request Created' event for each request.
- Use the AuditHistory.csv file to generate all other events. Map the values in the FieldName and NewValue columns to the required activity names, for example, if FieldName is 'Status' and NewValue is 'Resolved', the ActivityName becomes 'Service Request Resolved'.
- Join the transformed audit events back to the service request data using ParentLink_RecID from the audit file and RecId from the service request file. This adds the case-level attributes to every event.
- Combine the 'Created' events and the audit-derived events into a single table.
Format the final combined table with the required column headers: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate, and other recommended attributes. Ensure all timestamps are in a consistent format.
Save the final event log as a single CSV file, ready for upload.

Configuration

Business Objects: This method requires exporting from two separate business objects: ServiceReq for the main request data and FRS_data_audit_history for the event data.
Date Range Filter: It is critical to apply a date range filter to both exports to manage data volume. Use the CreatedDateTime field on ServiceReq and the AuditDate field on FRS_data_audit_history. A period of 3-6 months is recommended for initial analysis.
Key Filters for Audit History:
- ParentObjectType must be filtered to 'ServiceReq' to ensure you only extract changes related to service requests.
- You can optionally filter the FieldName to include only fields relevant to your process, such as 'Status', 'Owner', 'OwnerTeam', and 'Priority', which can significantly reduce the export size.
Prerequisites: A user account in Ivanti Service Manager with permissions to create Saved Searches and export data from the ServiceReq and FRS_data_audit_history business objects is required.
Performance Considerations: The FRS_data_audit_history table can be very large. Exporting data without a restrictive date filter can cause performance issues for the Ivanti application and may result in a timeout. Consider exporting data in smaller monthly or quarterly batches if necessary.

a Sample Query config

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

Steps

Prerequisites and Setup: Ensure you have Python 3.6 or higher installed on your system. Install the necessary libraries, requests for making API calls and pandas for data manipulation, by running pip install requests pandas. Obtain an API key from your Ivanti Service Manager administrator with at least read permissions for the ServiceReq and FRS_Audit_ServiceReq business objects.
Configure the Script: Download the provided Python script. Open the script in a text editor or IDE and update the placeholder variables at the top: TENANT_URL, API_KEY, START_DATE, and END_DATE to match your Ivanti environment and desired extraction window.
Execute the Script: Run the script from your command line using python your_script_name.py. The script will first print a message indicating it's connecting and authenticating with the Ivanti API.
Fetch Service Request Data: The script begins by querying the ServiceReq business object for all requests created within the specified date range. It automatically handles API pagination to retrieve the complete list of requests, printing progress updates as it fetches each page of data.
Fetch Audit History: For each service request retrieved, the script performs a secondary query on the FRS_Audit_ServiceReq business object. This fetches the complete field change history for that specific request, which is essential for building the detailed event log.
Generate 'Created' Event: As the script processes each service request, it first creates the 'Service Request Created' event. The timestamp for this event is taken directly from the CreatedDateTime field of the service request record.
Generate Events from Audit Trail: The script then iterates through the audit trail records for each service request. It analyzes each record to identify changes in key fields like Status, OwnerTeam, Owner, and Priority.
Map Changes to Activities: A predefined mapping logic within the script converts these field changes into specific activity names. For example, a change in the Status field from 'Active' to 'Resolved' is recorded as a 'Service Request Resolved' activity.
Construct the Event Log: All generated events, both the initial creation and the subsequent changes from the audit trail, are compiled into a structured list. Each event includes the Service Request ID, activity name, timestamp, and other relevant attributes.
Data Transformation and Formatting: The collected list of events is converted into a Pandas DataFrame. The script ensures all columns match the required schema for ProcessMind, including ServiceRequestID, ActivityName, and EventTime.
Export to CSV: Once all service requests and their histories have been processed, the script saves the final DataFrame to a CSV file named ivanti_servicereq_event_log.csv in the same directory where the script was run. This file is ready for upload.

Configuration

API Endpoint URL: The base URL for your Ivanti Service Manager tenant's REST API. This should be set in the TENANT_URL variable in the script, for example, https://your-tenant.ivanti.com.
API Key: A valid REST API key generated within the Ivanti administration console. This key must be associated with a role that has read permissions for the ServiceReq and FRS_Audit_ServiceReq business objects.
Date Range: The script requires a START_DATE and END_DATE in 'YYYY-MM-DD' format. For an initial analysis, a date range of 3 to 6 months is recommended to ensure a manageable data volume while capturing enough process variations.
Page Size (TOP_COUNT): This variable in the script defines the number of records to fetch per API call. The default is set to 500, which is a good balance for performance and memory usage. You can adjust this based on your API server's performance.
Required Fields (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): The script specifies which fields to retrieve from the API to minimize payload size. Ensure that all fields needed for the required and recommended attributes are included in these lists.

a Sample Query python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

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

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Ivanti Saved Search and Grid Data Export to CSV

Steps

Configuration

a Sample Query config

Python Script using the Ivanti REST API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Start Optimizing Your Service Request Management Today

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Ivanti Saved Search and Grid Data Export to CSV

Steps

Configuration

a Sample Query config

Python Script using the Ivanti REST API

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Start Optimizing Your Service Request Management Today