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

Your Service Request Management Data Template

Freshservice

Service Request Management Attributes (20) Service Request Management Activities (15) Extraction Guides (3)

Your Service Request Management Data Template

This template provides a comprehensive guide to collecting the necessary data for analyzing your Service Request Management process. It outlines the essential attributes, key activities to track, and practical guidance for extracting this information from your source systems. Use this resource to build a robust event log for in-depth process analysis.

Recommended attributes to collect
Key activities to track
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 a comprehensive analysis of your service request management process.

5 Required 5 Recommended 10 Optional

	Name	Description
	Activity Name ActivityName	The name of the event or task that occurred at a specific point in time for a service request.
Description The Activity Name describes a specific step or event within the service request lifecycle. These activities are extracted from system audit logs, status changes, or specific actions taken by users, such as 'Request Assigned to Agent', 'Note Added', or 'Service Request Resolved'. This attribute is crucial for constructing the process map, which visually represents the flow of service requests. By analyzing the sequence and frequency of different activities, organizations can understand the actual process, identify bottlenecks between steps, measure activity durations, and detect non-compliant or inefficient process variants. Why it matters This attribute defines the steps in the process map, allowing for the visualization and analysis of the service request workflow. Where to get Generated from the 'activities' or 'audits' associated with a ticket in Freshservice. This often requires transformation logic to map system events to business-friendly activity names. Examples Service Request CreatedRequest Assigned to AgentService Request ResolvedService Request Closed
	Event Time EventTime	The precise timestamp when the activity occurred.
Description Event Time captures the date and time that a specific activity was recorded for a service request. This timestamp is fundamental for sequencing events correctly and calculating durations between them. In process mining, this attribute is used to order the activities for each case and forms the basis for all time-based analysis. It is used to calculate cycle times, waiting times between activities, and adherence to service level agreements (SLAs). Accurate timestamps are critical for identifying bottlenecks and understanding process performance. Why it matters This timestamp orders events chronologically and is the foundation for all performance analysis, including cycle time and bottleneck detection. Where to get This corresponds to the creation timestamp of an activity or audit log entry within Freshservice. Examples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	Service Request ID ServiceRequestId	The unique identifier for each service request.
Description The Service Request ID is a unique number or code assigned to each new service request logged in Freshservice. It serves as the primary key for tracking the request's entire lifecycle, from creation to closure. In process mining, this ID is fundamental as it acts as the Case ID. All related events, such as status changes, agent assignments, and notes, are linked together using this identifier. Analyzing the journey of each Service Request ID allows for a complete end-to-end visualization of the process, identification of common pathways, and detection of deviations or bottlenecks affecting individual cases. Why it matters This is the essential Case ID that connects all related events, making it possible to trace the end-to-end journey of a single service request. Where to get This is a primary field on the ticket object in Freshservice. It is visible in the UI and available through the Freshservice API. Examples SR-12943SR-13501SR-14011
	Last Data Update LastDataUpdate	Timestamp indicating when the data was last refreshed from the source system.
Description This attribute records the date and time when the dataset was last extracted or updated from Freshservice. It provides context to the recency of the data being analyzed. For any process analysis, knowing the freshness of the data is critical. This timestamp helps users understand if they are looking at the most current information, which is essential for making timely operational decisions and for trusting the insights derived from the analysis. Why it matters Informs users about the recency of the data, ensuring that analyses and decisions are based on up-to-date information. Where to get This value is generated and stamped onto the dataset during the data extraction and transformation (ETL) process. Examples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Source System SourceSystem	Identifies the system from which the data was extracted.
Description This attribute specifies the originating system for the process data, which in this case is Freshservice. It is particularly useful in environments where data from multiple systems is being consolidated for a holistic process view. While it may seem redundant in a single-system analysis, it is a best practice to include this attribute for future scalability and data governance. It ensures clarity on data provenance and helps in managing data integration pipelines. Why it matters Ensures data provenance and traceability, which is crucial when combining data from multiple systems or for data governance purposes. Where to get This is typically a static value added during the data extraction and transformation (ETL) process. Examples FreshserviceFreshservice-API-v2
	Assigned Agent AssignedAgent	The name of the individual agent currently assigned to the service request.
Description This attribute identifies the specific support agent responsible for handling the service request at a given point in time. Agent assignments can change throughout the lifecycle of a request. Analyzing the Assigned Agent is key to understanding agent performance and workload distribution. It allows for the calculation of KPIs such as average resolution time per agent, number of active requests, and reassignment rates. This helps identify top-performing agents, agents who may need additional training, and imbalances in workload allocation. Why it matters Enables analysis of agent workload, performance, and the impact of reassignments on resolution times. Where to get Available as the 'agent' or 'responder' field on the ticket object in Freshservice. Examples Alice JohnsonRobert SmithUnassigned
	Assigned Team AssignedTeam	The support team or group assigned to handle the service request.
Description This attribute indicates the functional group or team, such as 'IT Support Level 2' or 'Hardware Procurement', that is responsible for the service request. A request may be assigned to a team before it is picked up by an individual agent. Analyzing by Assigned Team helps in understanding team-level performance, workload, and identifying bottlenecks specific to certain functional areas. It is crucial for assessing how efficiently different teams are processing requests and for optimizing resource allocation across the support organization. Why it matters Allows for performance and workload analysis at a team or group level, which is essential for resource management and identifying functional bottlenecks. Where to get Available as the 'group' field on the ticket object in Freshservice. Examples Service DeskNetwork OperationsApplication Support
	Priority Priority	The priority level of the service request, such as Low, Medium, High, or Urgent.
Description Priority indicates the importance and urgency of a service request, which often determines the target resolution time and the resources allocated. Priority can be set automatically based on rules or manually by agents. In process mining, Priority is a critical dimension for analysis. It is used to segment requests to compare process flows and performance for high-priority versus low-priority items. This is essential for SLA compliance analysis and for understanding if prioritization is happening effectively and quickly at the triage stage. Why it matters Crucial for SLA compliance analysis and for understanding if requests are being triaged and handled according to their business impact. Where to get Available as the 'priority' field on the ticket object in Freshservice. Examples LowMediumHighUrgent
	Service Type ServiceType	The specific type or category of the service being requested.
Description Service Type classifies the request based on the kind of service needed, such as 'New Hardware Request', 'Software Access', or 'Password Reset'. This is often linked to the service catalog item selected by the user. This attribute allows for the segmentation of service requests to compare processes and performance across different types of services. It is essential for calculating KPIs like 'Average Activity Count per Service Type', which helps identify which services are more complex or resource-intensive. This analysis can drive process simplification and automation efforts for specific service types. Why it matters Enables comparison of process flows and complexity across different categories of requests, helping to identify areas for standardization or automation. Where to get This often corresponds to the 'category', 'item', or a custom field on the ticket object in Freshservice, depending on configuration. Examples New Employee OnboardingSoftware License RequestVPN Access
	Status Status	The current status of the service request in its lifecycle.
Description The Status field represents the state of the service request at a given point in time, for example, 'Open', 'Pending', 'Resolved', or 'Closed'. Status changes are often the primary source of activities for process mining. Analyzing the Status provides context to the process flow and helps in understanding how much time requests spend in particular states. For instance, a long duration in the 'Pending' status could indicate a bottleneck waiting for requestor information or external vendor input. It's a key attribute for defining the start and end points of different process stages. Why it matters Provides crucial context for each event and helps measure the time spent in different states, such as 'Open' or 'Pending', to identify delays. Where to get Available as the 'status' field on the ticket object in Freshservice. Examples OpenPendingResolvedClosed
	Channel Channel	The method or channel through which the service request was submitted.
Description The Channel indicates how the service request was created, for example, via the self-service portal, email, phone call, or chat. This information helps in understanding user preferences and channel efficiency. Analyzing the process by channel can reveal important insights. For example, requests submitted via the portal may be more complete and resolved faster than those submitted via email, which might require more back-and-forth communication. This analysis can guide efforts to promote more efficient channels. Why it matters Helps analyze if the submission channel impacts the process efficiency, resolution time, or the amount of rework required. Where to get Available as the 'source' field on the ticket object in Freshservice. Examples EmailPortalPhoneChat
	End Time EndTime	The precise timestamp when the activity was completed.
Description The End Time represents the completion timestamp of an activity. For many events in Freshservice, the start and end time are the same, making them point-in-time events. However, for status-based activities, the End Time would be the timestamp of the next status change. This attribute is essential for calculating the duration of activities and waiting times between them. By subtracting the StartTime from the EndTime, the processing time for a specific task can be determined. This is crucial for identifying which activities are the most time-consuming and are primary candidates for optimization. Why it matters Enables the calculation of activity durations, which is fundamental for identifying bottlenecks and measuring processing times for individual steps. Where to get This is not a direct field in Freshservice logs. It needs to be derived by taking the timestamp of the subsequent event in the sequence for a given service request. Examples 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Is Rework IsRework	A boolean flag indicating if the request involved rework activities.
Description This calculated flag is set to true if a service request undergoes certain activities that are indicative of rework. Examples include being reopened after resolution ('Service Request Reopened'), multiple reassignments, or repeated requests for information from the user ('Information Requested from Requestor'). This attribute simplifies the analysis of process inefficiencies. It allows for easy filtering to isolate cases with rework and compare their process maps and cycle times to 'clean' cases. This directly supports the 'Service Request Rework Analysis' dashboard and helps quantify the impact of inefficient handoffs or incomplete initial information. Why it matters Provides a simple way to flag and analyze cases that involve inefficient loops or repeated steps, helping to quantify the cost of poor quality. Where to get Calculated during data transformation by applying business logic to the sequence of activities for each 'ServiceRequestId'. Examples truefalse
	Is SLA Breached IsSlaBreached	A boolean flag indicating if the service request exceeded its resolution SLA target.
Description This calculated attribute is a simple true or false flag that indicates whether the service request was closed after its SLA due date. It is derived by comparing the 'Service Request Closed' or 'Service Request Resolved' timestamp with the 'SlaDueDate'. This attribute simplifies analysis and visualization for the SLA Compliance dashboard. It allows for easy filtering and aggregation to calculate the overall SLA Compliance Rate KPI. Segmenting by this flag helps to quickly isolate and analyze the process characteristics of breached requests versus those that were resolved on time. Why it matters Simplifies SLA compliance analysis by providing a clear flag for filtering and aggregating requests that failed to meet their targets. Where to get This is a calculated field, derived during data transformation by comparing the final resolution timestamp to the 'SlaDueDate' field. Examples truefalse
	Processing Time ProcessingTime	The duration of time spent actively working on an activity.
Description Processing Time is a calculated metric that represents the duration of a single activity. It is computed by subtracting the activity's StartTime from its EndTime. This metric is fundamental for bottleneck analysis. By aggregating the processing times for each type of activity, a clear picture emerges of where the most time is being spent in the process. This allows analysts to focus improvement efforts on the most time-consuming steps, such as 'Internal Review Performed' or 'External Vendor Engaged'. Why it matters Quantifies the duration of individual process steps, directly highlighting the most time-consuming activities and bottlenecks. Where to get Calculated during data preparation by subtracting the 'EventTime' (StartTime) of an event from the 'EndTime' (the timestamp of the next event). Examples 360086400300
	Reassignment Count ReassignmentCount	The total number of times a service request has been reassigned to a different agent or team.
Description This is a calculated attribute that counts the occurrences of 'Request Reassigned' or similar activities for each service request. A high reassignment count often points to issues with initial triage, incorrect skill-based routing, or workload imbalances. This attribute directly supports the 'Agent Performance & Workload Distribution' dashboard and the 'Avg Agent Reassignment Count/Request' KPI. Analyzing this metric helps organizations identify process weaknesses that lead to tickets being passed around, which increases resolution time and frustrates both agents and requestors. Why it matters Measures routing inefficiency and process friction. A high count indicates problems with initial triage or agent workload, leading to delays. Where to get This is calculated by counting specific assignment change activities for each 'ServiceRequestId' during data transformation. Examples 013
	Requestor Requestor	The user who submitted the service request.
Description This attribute identifies the individual, usually an employee, who initiated the service request. It provides context about who is using the service desk and what their needs are. While not always a primary dimension for process flow analysis, analyzing by requestor or their associated department can uncover patterns. For instance, it might reveal that a specific department frequently submits incomplete requests, indicating a need for targeted training. It's also essential for any analysis focused on the customer experience. Why it matters Provides context about the user initiating the request, enabling analysis of request patterns by individual, department, or location. Where to get Available as the 'requester' field on the ticket object in Freshservice. Examples John DoeJane SmithService Account
	Requestor Department RequestorDepartment	The department to which the requestor belongs.
Description This attribute specifies the organizational department of the user who submitted the service request, such as 'Sales', 'Finance', or 'Human Resources'. This information is typically sourced from the user's profile in the system. Analyzing process performance by department is a common requirement. It can highlight if certain departments are experiencing longer resolution times or have unique process needs. This insight can inform resource allocation, training initiatives, or the creation of department-specific service offerings. Why it matters Allows for segmentation of the process by business unit, helping to identify department-specific issues or performance variations. Where to get This information is linked via the requestor's profile. It may be in a default 'department' field or a custom user field in Freshservice. Examples FinanceMarketingInformation Technology
	SLA Due Date SlaDueDate	The timestamp by which the service request is expected to be resolved according to its SLA.
Description This attribute specifies the deadline for resolving the service request as defined by the applicable SLA policy. It is a calculated timestamp based on the request's creation time, priority, and the business hours defined in the SLA. This is a critical data point for monitoring real-time performance and for post-mortem SLA compliance analysis. By comparing the actual resolution time with the SlaDueDate, a determination of 'Met' or 'Breached' can be made. It is the foundation for calculating the SLA Compliance Rate KPI. Why it matters This is the target deadline for resolution, forming the basis for calculating whether a service request met or breached its SLA. Where to get This is a calculated field within Freshservice, visible on the ticket as 'Due by'. It is available via the API. Examples 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	SLA Policy Name SlaPolicyName	The name of the Service Level Agreement (SLA) policy applied to the request.
Description This attribute identifies the specific SLA policy that governs the target response and resolution times for the service request. Policies are typically based on factors like priority, service type, or requestor group. Knowing which SLA policy is applied is essential for the SLA Compliance & Breach Analysis dashboard. It allows for accurate measurement of performance against defined targets and helps in analyzing which policies are most frequently breached. This can lead to reviews of either the process performance or the feasibility of the SLA targets themselves. Why it matters Identifies the specific service targets the request is measured against, which is essential for accurate SLA compliance reporting. Where to get This information is part of the SLA data associated with a ticket. It might require querying specific SLA-related API endpoints or fields. Examples High Priority Incidents - 4hrStandard Requests - 3 dayVIP Support - 1hr

Required Recommended Optional

Service Request Management Activities

These are the key process steps and milestones to capture in your event log for accurate discovery and analysis of your service request workflows.

6 Recommended 9 Optional

	Activity	Description
	External Vendor Engaged	This activity marks when a ticket is handed off to an external vendor or third party for resolution. It is inferred from a status change to a specific state like 'Pending Vendor' or 'Awaiting Third Party'.
Why it matters Vendor engagement can introduce significant delays. Tracking this activity is essential for measuring vendor performance and its impact on the overall service request cycle time. Where to get Inferred from the ticket's status change history. Look for a status specifically configured to track dependency on external vendors. Capture Detect when the ticket status field changes to a value indicating a wait for a third party. Event type inferred
	Request Assigned to Agent	Marks the point when a service request is assigned to a specific agent for handling. This is a key milestone and is inferred by tracking changes to the 'Assigned Agent' or 'Owner' field for the ticket.
Why it matters This activity is crucial for analyzing agent workload and identifying bottlenecks in the assignment process. The time between creation and assignment is a key performance indicator. Where to get Inferred from the ticket's activity log or field audit trail by monitoring changes to the 'Agent' or 'Assignee' field. Capture Capture the timestamp when the 'Assigned Agent' field is populated or its value changes. Event type inferred
	Service Request Closed	This is the final activity, signifying the end of the service request lifecycle. It typically occurs automatically after a set period of time in the 'Resolved' state without being reopened.
Why it matters This event marks the definitive end of the process instance. The time between 'Resolved' and 'Closed' represents the confirmation window for the requestor. Where to get Inferred from the ticket's status change history. It corresponds to the timestamp when the status changes to 'Closed'. Capture Capture the timestamp when the ticket status changes to 'Closed'. Event type inferred
	Service Request Created	This activity marks the beginning of the service request lifecycle when a new request is formally logged in Freshservice. This event is captured explicitly when a new ticket record is generated, either through the service catalog, email, or another channel, creating a unique Service Request ID.
Why it matters This is the primary start event for the process. Analyzing the time from this activity to others is fundamental for measuring overall cycle times and identifying initial processing delays. Where to get This event is explicitly recorded in Freshservice. It can be found in the ticket's activity log or audit trail, typically corresponding to the ticket creation timestamp. Capture Use the ticket creation timestamp from the Freshservice tickets data. Event type explicit
	Service Request Resolved	This critical milestone marks the point when the agent has provided a solution and considers the work complete. This is inferred from the ticket status changing to 'Resolved'.
Why it matters This activity signifies the end of the active work phase. The duration until this point is a key measure of agent and process efficiency, and it is the basis for SLA calculations. Where to get Inferred from the ticket's status change history. This corresponds to the timestamp when the status was first set to 'Resolved'. Capture Capture the timestamp when the ticket status first changes to 'Resolved'. Event type inferred
	SLA Target Breached	A calculated event that occurs when the time to resolve a service request exceeds its defined Service Level Agreement (SLA) target. This is not a direct system event but is derived by comparing the resolution time to the SLA due date.
Why it matters This directly measures service performance against commitments and is a key KPI for management. It helps identify which request types or priorities are most at risk of failing. Where to get Calculated by comparing the 'Resolved' timestamp with the 'SLA Due By' timestamp. If the resolution time is later, this event is triggered. Capture Compare resolution timestamp to the SLA due by timestamp. If resolved_at > sla_due_by, create this event. Event type calculated
	Information Provided by Requestor	Occurs when the requestor responds with the necessary information, allowing the agent to resume work. This is typically inferred when the ticket status automatically changes from a 'Pending' state back to 'Open'.
Why it matters This activity closes the loop on information requests. The duration between requesting and providing information is a critical waiting time to analyze and optimize. Where to get Inferred from a status change from a 'Pending' state back to an 'Open' or 'In Progress' state, often triggered by a reply from the requestor. Capture Detect when the ticket status changes from a pending state to an open state. Event type inferred
	Information Requested from Requestor	Represents a point where the assigned agent requires more information from the requestor and pauses progress. This is inferred from a ticket status change to a 'Pending' or 'Awaiting Customer' state.
Why it matters This activity highlights a common source of delay and rework. Analyzing its frequency helps identify opportunities to improve request templates and initial data collection. Where to get Inferred from the ticket's status change history. Look for a change to a status like 'Pending Customer Response' or 'Awaiting Information'. Capture Detect when the ticket status field changes to a value indicating a wait for user input. Event type inferred
	Internal Review Performed	Indicates that a proposed solution or request fulfillment requires an internal review or approval before proceeding. This is inferred from a status change to a state such as 'Pending Approval' or 'Internal Review'.
Why it matters Internal reviews can be a source of bottlenecks, especially in complex or high-impact service requests. Measuring this duration helps streamline approval workflows. Where to get Inferred from the ticket's status change history. This requires a specific status like 'Pending Internal Approval' to be used in the workflow. Capture Detect when the ticket status field changes to a value indicating an internal review or approval. Event type inferred
	Note Added	Represents any public or private note added to the service request by an agent or the requestor. This is an explicit event captured in the ticket's conversation or activity log.
Why it matters Analyzing the frequency and timing of notes can reveal communication patterns, collaboration efficiency, and points of confusion in the process. Where to get Explicitly logged in the ticket's conversation history in Freshservice. Each note has a timestamp and author. Capture Extract each entry from the ticket's conversation or comment log. Event type explicit
	Request Prioritized	This activity occurs when a priority level, such as Low, Medium, or High, is assigned to the service request. It is inferred by detecting a change in the 'Priority' field within the ticket's history.
Why it matters Prioritization is critical for resource allocation and ensuring SLA targets are met. Analyzing this activity helps verify that requests are assessed correctly and in a timely manner. Where to get Inferred from the ticket's field change history in Freshservice. Look for updates to the 'Priority' field and capture the timestamp of the change. Capture Detect a change in the 'Priority' field from null or its previous value and record the timestamp. Event type inferred
	Request Reassigned	This activity captures any change in the assigned agent or group after the initial assignment. It is inferred by detecting subsequent updates to the 'Assigned Agent' or 'Assigned Group' fields.
Why it matters Frequent reassignments indicate potential issues with initial triage, agent skill matching, or workload balancing. This activity is vital for the Agent Reassignment Count KPI and rework analysis. Where to get Inferred from the ticket's field change history. This event is logged every time the 'Assigned Agent' or 'Assigned Group' field is updated after its initial value was set. Capture Detect any change to the 'Assigned Agent' or 'Assigned Group' field after the first assignment. Event type inferred
	Request Triaged	Represents the initial assessment and categorization of a newly created service request. This activity is typically inferred from the first time a priority is set or the request is assigned to a group, indicating it has been reviewed and is entering the queue.
Why it matters Tracking triage helps measure the efficiency of the initial response team. Delays at this stage can significantly impact overall resolution times and SLA compliance. Where to get Inferred from the activity log. It can be identified by the timestamp of the first 'Priority Set' or 'Group Assigned' event that occurs after creation. Capture Identify the earliest timestamp of either a priority field change or an assignment group field change. Event type inferred
	Resolution Confirmed by Requestor	This activity represents an explicit confirmation from the requestor that the provided solution is satisfactory. This may be inferred from a positive survey response or a specific comment before the ticket is closed.
Why it matters Confirmation provides direct feedback on the quality of the resolution. A low confirmation rate may indicate that solutions are not fully meeting user needs, even if they are not reopened. Where to get This is difficult to capture directly and may require custom configuration. It could be inferred from a customer satisfaction survey response linked to the ticket, or a specific tag being applied. Capture Requires analysis of related data like satisfaction surveys or tags applied after resolution. Event type inferred
	Service Request Reopened	Occurs when a requestor indicates that an issue persists after it was marked as 'Resolved', causing the ticket to return to an open state. This is inferred from a status change from 'Resolved' back to 'Open' or 'In Progress'.
Why it matters Reopened requests are a strong indicator of low first-call resolution rates and customer dissatisfaction. Tracking this rework loop is critical for improving solution quality. Where to get Inferred from the ticket's status change history in the activity log. This is a direct status transition from 'Resolved' to 'Open'. Capture Detect a status change from a resolved state to an open state. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Freshservice

Steps

Prerequisite Check: Ensure you have a Freshservice user role with permissions to access and create reports in the Analytics module. This typically requires a Pro or Enterprise plan.
Configure Automations (If Needed): For accurate event capture, verify or create two specific automations in Freshservice under Admin -> Workflow Automator. First, an automation that adds a private note or a specific tag (e.g., 'SLA_Breached') to a ticket when its resolution SLA timer expires. Second, an automation that adds a specific tag (e.g., 'Resolution_Confirmed') when a positive customer satisfaction survey is received for a ticket.
Create the 'Creation Events' Report: Navigate to the Analytics tab in Freshservice. Create a new report and select the 'Tickets' module as the data source. This report will capture the first event for each service request.
Configure 'Creation Events' Report Widgets: Add a 'Data Table' widget. Configure the columns (metrics) to include: Ticket ID, Created at, Assigned to, Group, Priority, Status, and Category. Apply a filter for the desired creation date range, for instance, the last 6 months.
Export 'Creation Events' Data: Run the report and export the data table widget to a CSV file. Name it 'creation_events.csv'.
Create the 'Update Events' Report: Create a second report, this time selecting the 'Ticket Activities' module as the data source. This report captures all subsequent changes and notes for each service request.
Configure 'Update Events' Report Widgets: Add a 'Data Table' widget. Configure the columns to include: Ticket ID, Activity Date, Performed by, Activity Type, and under 'Changes', include Field, Old Value, and New Value. You should also add ticket-level attributes like Group, Assigned to, Priority, Status, and Category to provide context for each event.
Filter 'Update Events' Report: Apply a filter for the 'Activity Date' to match the same date range used in the creation report. Further filter the 'Activity Type' to include only relevant events like 'Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', and 'Public Note added'.
Export 'Update Events' Data: Run the report and export the data table widget to a CSV file. Name it 'update_events.csv'.
Combine and Transform Data: Open the two CSV files in a spreadsheet program or use a data preparation script. Copy all data from 'update_events.csv' and paste it below the data from 'creation_events.csv' into a new file named 'event_log.csv'.
Map Activities and Attributes: In the combined 'event_log.csv' file, create new columns: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status, and ServiceType. Populate these columns using the logic defined in the Query section below. This step involves using formulas or a script to translate the raw data into the final event log format.
Final Export: Save the transformed 'event_log.csv' file. Ensure the date format for EventTime and LastDataUpdate is in a standard format like ISO 8601. This file is now ready for upload into a process mining tool.

Configuration

Freshservice Plan: A plan that includes the Analytics module (typically Pro or Enterprise) is required.
User Permissions: The user performing the export needs permissions to create and run reports in Analytics.
Date Range: It is recommended to extract data for a recent period, such as the last 3 to 6 months, to keep the dataset manageable. Apply a consistent date range filter based on 'Created at' for the creation report and 'Activity Date' for the updates report.
Report Filters: In the 'Tickets' module report, filter by 'Type' = 'Service Request' to isolate the correct process. For the 'Ticket Activities' report, filter the 'Activity Type' to include only relevant changes (Status, Priority, Assignment, Notes) to reduce noise in the exported data.
Required Automations: The extraction of 'SLA Target Breached' and 'Resolution Confirmed by Requestor' activities depends on pre-existing Workflow Automator rules that add a note or tag to the ticket upon those events. Without these, the activities cannot be captured using this method.

a Sample Query config

/*
This extraction method uses the Freshservice UI. The following describes the configuration
and post-processing logic required to generate the event log.
*/

-- Step 1: Configuration for Report 1 (Creation Events)
MODULE: Tickets
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Created at
  - Assigned to
  - Group
  - Priority
  - Status
  - Category
FILTERS:
  - Created at IS WITHIN [Specify Start Date] and [Specify End Date]
  - Type EQUALS 'Service Request'

-- Step 2: Configuration for Report 2 (Update Events)
MODULE: Ticket Activities
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Activity Date
  - Activity Type
  - Field (from Changes)
  - Old Value (from Changes)
  - New Value (from Changes)
  - Performed by
  - Group (ticket attribute)
  - Assigned to (ticket attribute)
  - Priority (ticket attribute)
  - Status (ticket attribute)
  - Category (ticket attribute)
FILTERS:
  - Activity Date IS WITHIN [Specify Start Date] and [Specify End Date]
  - Ticket Type EQUALS 'Service Request'
  - Activity Type IN ('Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', 'Public Note added')

-- Step 3: Post-Processing Logic to create the final event log file
/* 
Apply this logic to each row of the combined data from the two exported CSV files.
The logic uses a CASE statement structure to map raw data to the final ActivityName.
*/

-- Column Mapping Logic:
`ServiceRequestId` = `Ticket ID`
`EventTime` = IF row is from creation_events.csv THEN `Created at` ELSE `Activity Date`
`SourceSystem` = 'Freshservice'
`LastDataUpdate` = CURRENT_TIMESTAMP()
`AssignedAgent` = `Assigned to`
`AssignedTeam` = `Group`
`Priority` = `Priority`
`Status` = `Status`
`ServiceType` = `Category`

-- ActivityName Mapping Logic:
CASE
  WHEN row is from creation_events.csv THEN 'Service Request Created'
  WHEN `Activity Type` = 'Group changed' AND `Old Value` IS NULL THEN 'Request Triaged'
  WHEN `Activity Type` = 'Priority changed' THEN 'Request Prioritized'
  WHEN `Activity Type` = 'Agent changed' AND `Old Value` IS NULL THEN 'Request Assigned to Agent'
  WHEN `Activity Type` IN ('Agent changed', 'Group changed') AND `Old Value` IS NOT NULL THEN 'Request Reassigned'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Customer', 'Awaiting Customer Response') THEN 'Information Requested from Requestor'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Pending Customer', 'Awaiting Customer Response') AND `New Value` = 'Open' THEN 'Information Provided by Requestor'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Vendor', 'Awaiting Third Party') THEN 'External Vendor Engaged'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Approval', 'Internal Review') THEN 'Internal Review Performed'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'SLA Breached' THEN 'SLA Target Breached' -- Requires custom automation
  WHEN `Activity Type` IN ('Private Note added', 'Public Note added') THEN 'Note Added'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Resolved', 'Closed') AND `New Value` IN ('Open', 'In Progress') THEN 'Service Request Reopened'
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Resolved' THEN 'Service Request Resolved'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'Resolution Confirmed' THEN 'Resolution Confirmed by Requestor' -- Requires custom automation
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Closed' THEN 'Service Request Closed'
  ELSE NULL -- Filter out these rows
END AS ActivityName

Steps

Prerequisites: Ensure you have Python 3.6 or newer installed on your system, along with the requests and pandas libraries. You will also need a Freshservice API key with permissions to read ticket data.
Obtain API Key: Log in to your Freshservice instance as an administrator. Click on your profile icon in the top right corner, go to 'Profile Settings', and you will find your API key on the right-hand pane. Copy this key securely.
Save the Script: Save the provided Python code into a file named extract_freshservice_srm.py on your local machine.
Configure Script Parameters: Open the saved script in a text editor. Locate the configuration section at the top and replace the placeholder values for FRESHSERVICE_DOMAIN, API_KEY, START_DATE, and END_DATE. Adjust the STATUS_MAPPING dictionary if your instance uses different numeric IDs for custom statuses.
Install Libraries: If you do not have the required libraries installed, open your command line or terminal and run the command: pip install requests pandas.
Execute the Script: Navigate to the directory where you saved the script using your command line or terminal. Run the script by executing the command: python extract_freshservice_srm.py.
Monitor Execution: The script will print progress updates to the console, showing which page of tickets it is currently processing. Depending on the date range and volume of tickets, this may take some time.
Retrieve the Event Log: Once the script finishes successfully, it will create a file named freshservice_event_log.csv in the same directory. This file contains the extracted event log.
Prepare for Upload: The generated CSV file is structured with the required columns (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) and is ready for upload into ProcessMind. No further formatting is typically needed.

Configuration

FRESHSERVICE_DOMAIN: Your organization's Freshservice URL, for example, yourcompany.freshservice.com.
API_KEY: The personal API key obtained from your Freshservice user profile. This should be kept confidential.
START_DATE / END_DATE: The date range for the ticket extraction, formatted as 'YYYY-MM-DD'. For an initial analysis, a range of 3 to 6 months is recommended to balance data volume and insight.
STATUS_MAPPING: A critical Python dictionary in the script that maps custom status names used for inferring events (like 'External Vendor Engaged') to their corresponding numeric status IDs in your Freshservice instance. You must verify and update these IDs to match your system's configuration.
API Rate Limiting: Be aware of your Freshservice plan's API rate limits. The script processes tickets sequentially to respect these limits, but for extremely large datasets, you may need to run the extraction in smaller date range batches.
Data Scope: The script is configured to only pull tickets of type 'Service Request'. This filter is applied during the initial ticket fetch.

a Sample Query python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain and API key
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com" 
API_KEY = class="hl-string">"[YOUR_API_KEY]"

class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Map your custom status names to their numeric IDs in Freshservice ---
class=class="hl-string">"hl-comment"># To find these IDs, you may need to inspect API responses or admin settings
class=class="hl-string">"hl-comment"># Common defaults: Open: 2, Pending: 3, Resolved: 4, Closed: 5
STATUS_MAPPING = {
    class="hl-string">'Open': 2,
    class="hl-string">'Pending': 3, 
    class="hl-string">'Resolved': 4, 
    class="hl-string">'Closed': 5,
    class="hl-string">'Awaiting Customer': 3, class=class="hl-string">"hl-comment"># Example, often maps to Pending
    class="hl-string">'Pending Vendor': [6], class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
    class="hl-string">'Pending Approval': [7]  class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
}
class=class="hl-string">"hl-comment"># --- END CONFIGURATION ---

BASE_URL = fclass="hl-string">"https://{FRESHSERVICE_DOMAIN}/api/v2"
AUTH = (API_KEY, class="hl-string">"X")

class=class="hl-string">"hl-comment"># Caching for agent and group lookups to reduce API calls
agent_cache = {}
group_cache = {}

def get_api_data(url):
    class="hl-string">"""Helper function to handle API requests and rate limiting."""
    while True:
        try:
            response = requests.get(url, auth=AUTH)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            return response.json()
        except requests.exceptions.HTTPError as e:
            if e.response.status_code == 429: class=class="hl-string">"hl-comment"># Rate limit exceeded
                print(class="hl-string">"Rate limit exceeded. Waiting for 60 seconds...")
                time.sleep(60)
                continue
            else:
                print(fclass="hl-string">"HTTP Error: {e}")
                return None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            return None

def get_agent_name(agent_id):
    class="hl-string">"""Fetch agent name by ID with caching."""
    if not agent_id: return None
    if agent_id in agent_cache:
        return agent_cache[agent_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/agents/{agent_id}")
    if data and class="hl-string">'agent' in data:
        name = data[class="hl-string">'agent'][class="hl-string">'first_name'] + class="hl-string">' ' + data[class="hl-string">'agent'][class="hl-string">'last_name']
        agent_cache[agent_id] = name
        return name
    return None

def get_group_name(group_id):
    class="hl-string">"""Fetch group name by ID with caching."""
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/groups/{group_id}")
    if data and class="hl-string">'group' in data:
        name = data[class="hl-string">'group'][class="hl-string">'name']
        group_cache[group_id] = name
        return name
    return None

def parse_iso_datetime(dt_string):
    if not dt_string: return None
    return datetime.fromisoformat(dt_string.replace(class="hl-string">'Z', class="hl-string">'+00:00'))

def main():
    event_log = []
    last_data_update = datetime.now().isoformat()

    page = 1
    while True:
        print(fclass="hl-string">"Fetching tickets, page {page}...")
        query = fclass="hl-string">'"created_at:>\\'{START_DATE}\\class="hl-string">' AND created_at:<\\'{END_DATE}\\class="hl-string">' AND ticket_type:\\\'Service Request\\\class="hl-string">'"'
        url = fclass="hl-string">"{BASE_URL}/tickets?query={query}&page={page}&per_page=100"

        data = get_api_data(url)

        if not data or class="hl-string">'tickets' not in data or not data[class="hl-string">'tickets']:
            break

        tickets = data[class="hl-string">'tickets']

        for ticket in tickets:
            service_request_id = ticket[class="hl-string">'id']
            created_at = parse_iso_datetime(ticket[class="hl-string">'created_at'])
            due_by = parse_iso_datetime(ticket[class="hl-string">'due_by'])
            resolved_at = parse_iso_datetime(ticket[class="hl-string">'resolved_at'])
            closed_at = parse_iso_datetime(ticket[class="hl-string">'closed_at'])

            class=class="hl-string">"hl-comment"># --- Activity: Service Request Created ---
            event_log.append({
                class="hl-string">'ServiceRequestId': service_request_id,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
                class="hl-string">'EventTime': created_at,
                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                class="hl-string">'LastDataUpdate': last_data_update,
                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                class="hl-string">'Status': ticket[class="hl-string">'status'],
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
            })
            
            class=class="hl-string">"hl-comment"># Fetch conversations for detailed history
            conv_url = fclass="hl-string">"{BASE_URL}/tickets/{service_request_id}/conversations"
            conversations = get_api_data(conv_url)
            
            if not conversations or class="hl-string">'conversations' not in conversations:
                continue
                
            class=class="hl-string">"hl-comment"># Sort conversations chronologically
            sorted_convos = sorted(conversations[class="hl-string">'conversations'], key=lambda x: parse_iso_datetime(x[class="hl-string">'created_at']))

            initial_group_assigned = False
            initial_priority_set = False
            initial_agent_assigned = False
            triaged = False

            for conv in sorted_convos:
                conv_time = parse_iso_datetime(conv[class="hl-string">'created_at'])

                class=class="hl-string">"hl-comment"># --- Activity: Note Added ---
                if conv[class="hl-string">'body_text']:
                     event_log.append({
                        class="hl-string">'ServiceRequestId': service_request_id,
                        class="hl-string">'ActivityName': class="hl-string">'Note Added',
                        class="hl-string">'EventTime': conv_time,
                        class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                        class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                        class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                        class="hl-string">'Status': ticket[class="hl-string">'status'],
                        class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                    })

                class=class="hl-string">"hl-comment"># Process system activities from the activity log within conversations
                if class="hl-string">'activities' in conv and conv[class="hl-string">'activities']:
                    for activity in conv[class="hl-string">'activities']:
                        shipping_info = activity.get(class="hl-string">'shipping_info', {})
                        changes = shipping_info.get(class="hl-string">'changes', {})
                        
                        class=class="hl-string">"hl-comment"># --- Priority Change Activities ---
                        if class="hl-string">'priority' in changes:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Request Prioritized',
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': changes[class="hl-string">'priority'][1], class=class="hl-string">"hl-comment"># New value
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            if not initial_priority_set and not triaged:
                                initial_priority_set = True
                                triaged = True
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Request Triaged'})
                        
                        class=class="hl-string">"hl-comment"># --- Assignment Change Activities ---
                        if class="hl-string">'responder_id' in changes:
                            activity_name = class="hl-string">'Request Assigned to Agent' if not initial_agent_assigned else class="hl-string">'Request Reassigned'
                            initial_agent_assigned = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(changes[class="hl-string">'responder_id'][1]),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        if class="hl-string">'group_id' in changes:
                            activity_name = class="hl-string">'Request Reassigned' class=class="hl-string">"hl-comment"># Any group change after creation is a reassignment
                            if not initial_group_assigned and not triaged:
                                activity_name = class="hl-string">'Request Triaged'
                                initial_group_assigned = True
                                triaged = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(changes[class="hl-string">'group_id'][1]),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        class=class="hl-string">"hl-comment"># --- Status Change Activities ---
                        if class="hl-string">'status' in changes:
                            old_status, new_status = changes[class="hl-string">'status']
                            
                            if new_status == STATUS_MAPPING[class="hl-string">'Resolved']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Closed']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Closed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Requested from Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer'] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Provided by Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status in [STATUS_MAPPING[class="hl-string">'Resolved'], STATUS_MAPPING[class="hl-string">'Closed']] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Reopened', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Vendor']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'External Vendor Engaged', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Approval']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Internal Review Performed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
            
            class=class="hl-string">"hl-comment"># --- Derived/Calculated Activities ---
            class=class="hl-string">"hl-comment"># --- Activity: SLA Target Breached ---
            resolution_time = closed_at or resolved_at
            if due_by and resolution_time and resolution_time > due_by:
                event_log.append({
                    class="hl-string">'ServiceRequestId': service_request_id,
                    class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                    class="hl-string">'EventTime': due_by,
                    class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                    class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                    class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                    class="hl-string">'Status': ticket[class="hl-string">'status'],
                    class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                })

            class=class="hl-string">"hl-comment"># --- Activity: Resolution Confirmed by Requestor (Inferred from survey) ---
            if ticket.get(class="hl-string">'satisfaction_ratings'):
                for rating in ticket[class="hl-string">'satisfaction_ratings']:
                    if rating.get(class="hl-string">'ratings'): class=class="hl-string">"hl-comment"># Check if there is a rating
                        rating_time = parse_iso_datetime(rating.get(class="hl-string">'created_at'))
                        if resolved_at and rating_time > resolved_at:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Resolution Confirmed by Requestor',
                                class="hl-string">'EventTime': rating_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            break class=class="hl-string">"hl-comment"># Only add one confirmation event

        page += 1

    if not event_log:
        print(class="hl-string">"No events were generated. Please check your configuration and date range.")
        return

    class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTime'])
    df[class="hl-string">'EventTime'] = df[class="hl-string">'EventTime'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    df[class="hl-string">'LastDataUpdate'] = pd.to_datetime(df[class="hl-string">'LastDataUpdate']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    output_filename = class="hl-string">'freshservice_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {output_filename}")

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

Steps

Prerequisite Check: Ensure you have a Freshservice user role with permissions to access and create reports in the Analytics module. This typically requires a Pro or Enterprise plan.
Configure Automations (If Needed): For accurate event capture, verify or create two specific automations in Freshservice under Admin -> Workflow Automator. First, an automation that adds a private note or a specific tag (e.g., 'SLA_Breached') to a ticket when its resolution SLA timer expires. Second, an automation that adds a specific tag (e.g., 'Resolution_Confirmed') when a positive customer satisfaction survey is received for a ticket.
Create the 'Creation Events' Report: Navigate to the Analytics tab in Freshservice. Create a new report and select the 'Tickets' module as the data source. This report will capture the first event for each service request.
Configure 'Creation Events' Report Widgets: Add a 'Data Table' widget. Configure the columns (metrics) to include: Ticket ID, Created at, Assigned to, Group, Priority, Status, and Category. Apply a filter for the desired creation date range, for instance, the last 6 months.
Export 'Creation Events' Data: Run the report and export the data table widget to a CSV file. Name it 'creation_events.csv'.
Create the 'Update Events' Report: Create a second report, this time selecting the 'Ticket Activities' module as the data source. This report captures all subsequent changes and notes for each service request.
Configure 'Update Events' Report Widgets: Add a 'Data Table' widget. Configure the columns to include: Ticket ID, Activity Date, Performed by, Activity Type, and under 'Changes', include Field, Old Value, and New Value. You should also add ticket-level attributes like Group, Assigned to, Priority, Status, and Category to provide context for each event.
Filter 'Update Events' Report: Apply a filter for the 'Activity Date' to match the same date range used in the creation report. Further filter the 'Activity Type' to include only relevant events like 'Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', and 'Public Note added'.
Export 'Update Events' Data: Run the report and export the data table widget to a CSV file. Name it 'update_events.csv'.
Combine and Transform Data: Open the two CSV files in a spreadsheet program or use a data preparation script. Copy all data from 'update_events.csv' and paste it below the data from 'creation_events.csv' into a new file named 'event_log.csv'.
Map Activities and Attributes: In the combined 'event_log.csv' file, create new columns: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status, and ServiceType. Populate these columns using the logic defined in the Query section below. This step involves using formulas or a script to translate the raw data into the final event log format.
Final Export: Save the transformed 'event_log.csv' file. Ensure the date format for EventTime and LastDataUpdate is in a standard format like ISO 8601. This file is now ready for upload into a process mining tool.

Configuration

Freshservice Plan: A plan that includes the Analytics module (typically Pro or Enterprise) is required.
User Permissions: The user performing the export needs permissions to create and run reports in Analytics.
Date Range: It is recommended to extract data for a recent period, such as the last 3 to 6 months, to keep the dataset manageable. Apply a consistent date range filter based on 'Created at' for the creation report and 'Activity Date' for the updates report.
Report Filters: In the 'Tickets' module report, filter by 'Type' = 'Service Request' to isolate the correct process. For the 'Ticket Activities' report, filter the 'Activity Type' to include only relevant changes (Status, Priority, Assignment, Notes) to reduce noise in the exported data.
Required Automations: The extraction of 'SLA Target Breached' and 'Resolution Confirmed by Requestor' activities depends on pre-existing Workflow Automator rules that add a note or tag to the ticket upon those events. Without these, the activities cannot be captured using this method.

a Sample Query config

/*
This extraction method uses the Freshservice UI. The following describes the configuration
and post-processing logic required to generate the event log.
*/

-- Step 1: Configuration for Report 1 (Creation Events)
MODULE: Tickets
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Created at
  - Assigned to
  - Group
  - Priority
  - Status
  - Category
FILTERS:
  - Created at IS WITHIN [Specify Start Date] and [Specify End Date]
  - Type EQUALS 'Service Request'

-- Step 2: Configuration for Report 2 (Update Events)
MODULE: Ticket Activities
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Activity Date
  - Activity Type
  - Field (from Changes)
  - Old Value (from Changes)
  - New Value (from Changes)
  - Performed by
  - Group (ticket attribute)
  - Assigned to (ticket attribute)
  - Priority (ticket attribute)
  - Status (ticket attribute)
  - Category (ticket attribute)
FILTERS:
  - Activity Date IS WITHIN [Specify Start Date] and [Specify End Date]
  - Ticket Type EQUALS 'Service Request'
  - Activity Type IN ('Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', 'Public Note added')

-- Step 3: Post-Processing Logic to create the final event log file
/* 
Apply this logic to each row of the combined data from the two exported CSV files.
The logic uses a CASE statement structure to map raw data to the final ActivityName.
*/

-- Column Mapping Logic:
`ServiceRequestId` = `Ticket ID`
`EventTime` = IF row is from creation_events.csv THEN `Created at` ELSE `Activity Date`
`SourceSystem` = 'Freshservice'
`LastDataUpdate` = CURRENT_TIMESTAMP()
`AssignedAgent` = `Assigned to`
`AssignedTeam` = `Group`
`Priority` = `Priority`
`Status` = `Status`
`ServiceType` = `Category`

-- ActivityName Mapping Logic:
CASE
  WHEN row is from creation_events.csv THEN 'Service Request Created'
  WHEN `Activity Type` = 'Group changed' AND `Old Value` IS NULL THEN 'Request Triaged'
  WHEN `Activity Type` = 'Priority changed' THEN 'Request Prioritized'
  WHEN `Activity Type` = 'Agent changed' AND `Old Value` IS NULL THEN 'Request Assigned to Agent'
  WHEN `Activity Type` IN ('Agent changed', 'Group changed') AND `Old Value` IS NOT NULL THEN 'Request Reassigned'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Customer', 'Awaiting Customer Response') THEN 'Information Requested from Requestor'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Pending Customer', 'Awaiting Customer Response') AND `New Value` = 'Open' THEN 'Information Provided by Requestor'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Vendor', 'Awaiting Third Party') THEN 'External Vendor Engaged'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Approval', 'Internal Review') THEN 'Internal Review Performed'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'SLA Breached' THEN 'SLA Target Breached' -- Requires custom automation
  WHEN `Activity Type` IN ('Private Note added', 'Public Note added') THEN 'Note Added'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Resolved', 'Closed') AND `New Value` IN ('Open', 'In Progress') THEN 'Service Request Reopened'
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Resolved' THEN 'Service Request Resolved'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'Resolution Confirmed' THEN 'Resolution Confirmed by Requestor' -- Requires custom automation
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Closed' THEN 'Service Request Closed'
  ELSE NULL -- Filter out these rows
END AS ActivityName

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Freshservice Analytics Module Data Export

Steps

Configuration

a Sample Query config

Python Script using Freshservice REST API

Steps

Configuration

a Sample Query python

Freshservice Scheduled Data Export to Cloud Storage

Steps

Configuration

a Sample Query config

Ready to Get Started?

Boost Service Request Efficiency in Freshservice Today

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Freshservice Analytics Module Data Export

Steps

Configuration

a Sample Query config

Python Script using Freshservice REST API

Steps

Configuration

a Sample Query python

Freshservice Scheduled Data Export to Cloud Storage

Steps

Configuration

a Sample Query config

We value your privacy

Ready to Get Started?

Boost Service Request Efficiency in Freshservice Today