> Continuous Process Improvement > Incident Management > Freshservice > Data Template

Data Template: Incident Management

Freshservice

Incident Management Attributes (20) Incident Management Activities (14) Extraction Guides (3)

Your Incident Management Data Template

This template is designed to help you prepare your data for effective incident management analysis. It outlines the essential attributes to collect, the critical activities to track, and provides practical guidance on extracting this information from your source system. Use this resource to streamline your data preparation process.

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

Incident Management Attributes

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

5 Required 7 Recommended 8 Optional

	Name	Description
	Incident ID IncidentId	The unique identifier for each incident record, serving as the primary key for tracking the entire incident lifecycle.
Description The Incident ID is the cornerstone of incident management analysis. It functions as the Case ID, linking all related activities, timestamps, and attribute changes into a single, cohesive journey. In process mining, every event log entry is associated with an Incident ID, allowing the reconstruction of the end-to-end process flow for each incident. This is essential for calculating cycle times, analyzing process variants, and identifying bottlenecks specific to individual cases. Without a unique identifier, it would be impossible to distinguish between different incidents and analyze their paths from reporting to resolution. Why it matters It uniquely identifies each incident, enabling the end-to-end tracking and analysis of its lifecycle from creation to closure. Where to get This is the primary identifier for a ticket, available via the Freshservice Tickets API as the 'id' field in the ticket object. Examples INC-10234INC-10235INC-10236
	Activity Name ActivityName	The name of the specific business activity or event that occurred at a point in time within the incident lifecycle.
Description The Activity Name describes a single step or event in the incident management process, such as 'Incident Assigned to Group', 'Status Changed to Pending', or 'Incident Resolved'. These activities are derived from changes in the incident's data over time. This attribute is fundamental to process mining as it defines the nodes in the discovered process map. By analyzing the sequence and frequency of these activities, organizations can visualize the actual incident resolution process, identify common pathways, detect deviations from the standard procedure, and pinpoint rework loops like frequent reassignments. Why it matters It defines the steps in the process map, allowing for visualization and analysis of the incident resolution flow, bottlenecks, and deviations. Where to get This attribute is not a direct field in Freshservice but is derived from changes in ticket properties like status, priority, agent/group assignment, and the addition of notes. Examples Incident ReportedIncident Assigned to GroupResolution Note AddedIncident Resolved
	Event Timestamp EventTimestamp	The exact date and time when the activity or event occurred.
Description The Event Timestamp, or Start Time, marks the precise moment an activity took place. Each activity in the incident's lifecycle, from creation to closure, has an associated timestamp. This attribute is critical for all time-based process mining analyses. It is used to order events chronologically, calculate the duration between activities, measure total case cycle time, and analyze waiting times. It is the foundation for building dashboards that track SLA performance, handoff delays, and overall resolution times. Why it matters It provides the chronological order of events, which is essential for calculating durations, analyzing cycle times, and understanding process performance. Where to get This is derived from various timestamp fields in Freshservice, such as 'created_at', 'updated_at', and timestamps within the ticket's conversation or audit logs. Examples 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Last Data Update LastDataUpdate	The timestamp indicating the last time the data for this process was refreshed or extracted.
Description This attribute provides a timestamp for when the entire dataset was last updated from the source system. It is a metadata field that applies to the whole dataset rather than individual events, but it is often included at the event level for consistency. In analysis, this information is vital for understanding the freshness of the data and the time window covered by the dashboards and KPIs. It gives users confidence in the recency of the insights and helps manage expectations about whether the very latest incidents are included in the analysis. Why it matters It informs users about the recency of the data, ensuring they understand the time frame covered by the analysis. Where to get This is a metadata timestamp generated during the data extraction (ETL) process. Examples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Source System SourceSystem	The system from which the data was extracted, typically 'Freshservice'.
Description This attribute identifies the origin of the data. While in this context it will consistently be 'Freshservice', it is a crucial field in environments where data from multiple systems might be combined for a holistic process view. Including the Source System attribute is a best practice for data governance and traceability. It ensures clarity on data provenance, which is important for validation, debugging, and future expansion of the process mining project to include other service management or operational systems. Why it matters It ensures data traceability and governance by clearly identifying the origin of the incident management data. Where to get This is typically a static value added during the data transformation (ETL) process to label the dataset. Examples FreshserviceFreshservice-EUFreshservice-PROD
	Assigned Agent AssignedAgent	The name or ID of the support agent currently assigned to resolve the incident.
Description The Assigned Agent identifies the individual service desk employee responsible for the incident at a given point in time. Changes to this attribute represent a transfer of ownership between agents. This attribute is essential for performance analysis, enabling dashboards that track agent workload, average resolution time per agent, and first contact resolution rates. It is also used to analyze handoffs between agents, which can be a source of delay and inefficiency. By tracking agent assignments, managers can identify training needs and recognize high-performing team members. Why it matters It enables analysis of agent performance, workload distribution, and the impact of agent handoffs on resolution times. Where to get Available in the Freshservice Tickets API as the 'responder_id' field. This ID can be joined with the Agents API to get the agent's name. Examples John DoeJane SmithSupportBot
	Assigned Group AssignedGroup	The support group or team currently assigned to the incident.
Description The Assigned Group indicates which team, such as 'Level 1 Support', 'Network Team', or 'Database Admins', is responsible for the incident. Changes to this attribute signify an escalation or transfer between different functional teams. Analyzing the Assigned Group is critical for understanding handoff and transfer delays. Process mining can visualize the flow of incidents between groups, highlighting common escalation paths and measuring the time spent waiting for each group to take action. This helps identify organizational bottlenecks and opportunities to streamline cross-team collaboration. Why it matters It tracks which team is responsible, which is crucial for analyzing handoffs, escalations, and inter-team delays. Where to get Available in the Freshservice Tickets API as the 'group_id' field. This ID can be joined with the Groups API to get the group's name. Examples Service DeskNetwork OperationsInfrastructure Support
	Incident Category IncidentCategory	The category used to classify the incident, such as Hardware, Software, or Network.
Description Incident Category provides a way to classify incidents based on the type of issue being reported. This hierarchical classification helps in routing the incident to the correct team and is vital for trend analysis. This attribute is used in the 'Incident Categorization Accuracy' dashboard to analyze if initial miscategorization leads to longer resolution times due to reassignments. By grouping incidents by category, organizations can identify recurring problems, understand where most support effort is spent, and tailor improvement initiatives. Why it matters It allows for the analysis of incident trends and helps determine if incorrect categorization is causing resolution delays. Where to get This is a default but customizable field in Freshservice. It is available in the Tickets API as 'category', with related fields 'sub_category' and 'item_category'. Examples HardwareSoftwareNetwork IssueAccount Access
	Incident Priority IncidentPriority	The priority level of the incident, which determines the urgency of response and resolution.
Description Incident Priority is a key field that dictates the required speed and focus for handling an incident. It is typically defined on a scale such as Low, Medium, High, and Urgent, and often drives SLA targets. In process mining, priority is a critical dimension for filtering and analysis. It allows for comparing the resolution processes for high-priority versus low-priority incidents, ensuring that critical issues are being handled efficiently. Dashboards often segment metrics like cycle time and SLA adherence by priority to provide actionable insights to support managers. Why it matters It helps prioritize analysis on the most critical incidents and is essential for evaluating SLA performance and resource allocation. Where to get Available in the Freshservice Tickets API as the 'priority' field. The values are numeric (e.g., 1 for Low, 4 for Urgent). Examples LowMediumHighUrgent
	Incident Severity IncidentSeverity	The severity level of the incident, indicating its business impact.
Description Incident Severity measures the impact an incident has on the business, often categorized as Low, Medium, High, or Critical. While related to priority, severity focuses on impact, whereas priority focuses on urgency. The combination of severity and impact often determines the final priority. Analyzing by severity helps in understanding how well the organization handles incidents with significant business consequences. It is used in dashboards to segment resolution times and SLA performance, ensuring that the most impactful issues receive the appropriate level of attention and resources throughout their lifecycle. Why it matters It measures the business impact of an incident, allowing for analysis focused on mitigating the most damaging issues. Where to get This is a default field in Freshservice, available via the Tickets API as 'impact'. The values are numeric. Examples LowMediumHigh
	Incident Status IncidentStatus	The current status of the incident in its lifecycle, such as Open, Pending, Resolved, or Closed.
Description The Incident Status indicates the incident's current state. Status changes are key events that form the basis of the discovered process map, such as moving from 'In Progress' to 'Pending' or from 'Resolved' to 'Closed'. This attribute is fundamental for understanding the incident's journey. Analyzing the time spent in each status helps identify bottlenecks, such as incidents spending too long in a 'Pending' state waiting for user response. It is also crucial for defining the start and end points for cycle time calculations. Why it matters It tracks the incident's progress through its lifecycle and helps identify stages where delays are common. Where to get Available in the Freshservice Tickets API as the 'status' field. The values are numeric. Examples OpenIn ProgressPendingResolvedClosed
	Resolution SLA Target Time ResolutionSlaTargetTime	The timestamp by which the incident is expected to be resolved according to its SLA policy.
Description This attribute stores the specific date and time that serves as the deadline for resolving an incident. This target is determined by the Service Level Agreement (SLA) policy applied to the ticket, which typically depends on factors like priority. This target time is essential for calculating the 'SLA Adherence Rate' KPI and powering the 'SLA Performance Dashboard'. By comparing the actual resolution timestamp with this target, we can determine if an incident was resolved on time or breached its SLA. This is fundamental for measuring service level compliance. Why it matters It provides the deadline for resolution, which is necessary for calculating SLA compliance and identifying at-risk incidents. Where to get Available in the Freshservice Tickets API as the 'fr_due_by' (first response) and 'due_by' (resolution) fields. Examples 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Handoff Count HandoffCount	The number of times an incident was transferred between different agents or groups.
Description Handoff Count is a calculated metric that quantifies the number of reassignments an incident undergoes during its lifecycle. Each change in the 'AssignedAgent' or 'AssignedGroup' attribute increments this count. A high handoff count is often an indicator of process inefficiency, incorrect initial routing, or a lack of agent expertise. This metric directly supports the 'Incident Handoff Count' KPI and the 'Handoff And Transfer Delay Analysis' dashboard, helping to identify incidents or process paths with excessive transfers that lead to delays. Why it matters It quantifies rework and reassignments, helping to identify inefficiencies caused by incorrect routing or knowledge gaps. Where to get This is a calculated metric derived by counting the number of distinct values or changes in the 'AssignedAgent' or 'AssignedGroup' fields over the lifecycle of a single incident. Examples 0125
	Is Reopened IsReopened	A calculated flag that is true if an incident was reopened after being resolved or closed.
Description This boolean attribute is a calculated flag that identifies incidents that have been reopened. It is set to true if an incident, after reaching a 'Resolved' or 'Closed' state, has its status changed back to an open or in-progress state. This flag is critical for calculating the 'Incident Reopening Rate' KPI and for the 'Recurring Incidents' dashboard. A high rate of reopened incidents can signal issues with the quality of the initial resolution, incomplete root cause analysis, or premature closure. Analyzing these cases helps improve the quality and sustainability of fixes. Why it matters It identifies failures in the resolution process, highlighting incidents where the initial fix was ineffective and leading to rework. Where to get This is a calculated field derived from the sequence of activities in the event log. It is true if an activity like 'Incident Reopened' occurs or if an open-state activity follows a closed-state one for the same Incident ID. Examples truefalse
	Is SLA Breached IsSlaBreached	A calculated flag that is true if the incident was not resolved within its defined SLA target time.
Description This boolean attribute is a calculated metric that indicates whether an incident's resolution time exceeded its SLA target. It is derived by comparing the actual resolution timestamp to the 'ResolutionSlaTargetTime'. This flag is a direct input for the 'SLA Adherence Rate' KPI and the 'SLA Performance Dashboard'. It simplifies analysis by providing a clear, binary outcome for each incident's SLA performance, allowing for easy aggregation and trend analysis. It helps quickly identify the volume and percentage of incidents that fail to meet service commitments. Why it matters It directly measures SLA compliance for each incident, making it easy to calculate overall adherence rates and identify problem areas. Where to get This is a calculated field, derived during data transformation by comparing the 'Incident Resolved' timestamp with the 'ResolutionSlaTargetTime' field. Examples truefalse
	Reporting Channel ReportingChannel	The method or channel through which the incident was reported, such as Email, Portal, or Phone.
Description The Reporting Channel, also known as the source, identifies how an incident entered the support system. Common channels include email, a self-service portal, phone calls, or chat. Analyzing this attribute helps evaluate the efficiency of different reporting channels. The 'Reporting Channel Efficiency' dashboard compares incident volume and average resolution time by channel to determine which methods are most effective and which may require process improvements. For example, incidents reported via the portal may be resolved faster if they contain more structured information from the start. Why it matters It helps identify the most efficient reporting channels and reveals opportunities to improve the incident intake process. Where to get Available in the Freshservice Tickets API as the 'source' field. The values are numeric. Examples EmailPortalPhoneChat
	Requester's Department RequestersDepartment	The department to which the user who reported the incident belongs.
Description This attribute identifies the business department of the requester, such as 'Sales', 'Finance', or 'IT'. This information is typically sourced from the user's profile within Freshservice. Analyzing incidents by the requester's department can reveal if certain business units are disproportionately affected by issues or if there are department-specific problems. It provides valuable context for understanding the business impact of incidents and can help prioritize fixes that affect critical departments. Why it matters It provides business context, allowing analysis of incident trends and impacts on specific departments. Where to get This information is linked to the requester of the ticket. It can be retrieved from the 'Requesters' API endpoint using the 'requester_id' from the ticket, then accessing the 'department_id' and name. Examples SalesMarketingFinanceHuman Resources
	Resolution Cycle Time ResolutionCycleTime	The total time elapsed from when an incident was first reported to when it was resolved.
Description Resolution Cycle Time is a key performance indicator calculated for each incident. It measures the total duration of the incident management process from the user's viewpoint, spanning from the initial report to the confirmation of resolution. This calculated metric is the foundation of the 'Incident Resolution Cycle Time' dashboard. It is used to measure overall process efficiency and is often analyzed across different dimensions like priority, category, and agent. Identifying incidents with long cycle times helps pinpoint systemic delays and inefficiencies. Why it matters It is a primary measure of process performance, directly indicating how long it takes to resolve incidents from start to finish. Where to get This is a calculated metric. It is the difference between the timestamp of the 'Incident Resolved' activity and the 'Incident Reported' activity. Examples 259200000864000003600000
	Root Cause RootCause	The underlying reason or root cause identified for the incident after investigation.
Description The Root Cause attribute captures the fundamental issue that led to the incident. This information is typically filled in by support agents during or after the resolution as part of a root cause analysis (RCA) process. This attribute is crucial for the 'Recurring Incidents And Root Causes' dashboard and the 'Root Cause Analysis Completion Rate' KPI. By analyzing common root causes, organizations can move from reactive incident fixing to proactive problem management, implementing permanent solutions that prevent future incidents and reduce recurring issues. Why it matters It enables proactive problem management by helping to identify and eliminate the underlying causes of recurring incidents. Where to get This is often a custom field in Freshservice, as default functionality may be limited. Check the 'Ticket Fields' configuration for a field named 'Root Cause' or similar. Examples Software BugNetwork Configuration ErrorUser Training IssueHardware Failure
	Workaround Provided WorkaroundProvided	A flag indicating whether a temporary workaround was provided to the user before the final resolution.
Description This boolean attribute indicates if a temporary fix or workaround was implemented to mitigate the incident's impact while a permanent solution was being developed. This is often tracked via a checkbox or a specific status. In process mining, this attribute supports the 'Workaround Effectiveness Metrics' dashboard. It allows for a comparison of resolution times for incidents with and without workarounds, helping to determine if providing temporary fixes effectively reduces business disruption and contributes to a faster overall resolution from the user's view. Why it matters It helps measure the effectiveness of temporary workarounds in reducing incident impact and accelerating perceived resolution. Where to get This is typically a custom boolean (checkbox) field. Its existence must be verified in the Freshservice 'Ticket Fields' configuration. Examples truefalse

Required Recommended Optional

Incident Management Activities

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

7 Recommended 7 Optional

	Activity	Description
	Incident Assigned to Group	Represents the initial assignment of an incident to a support group. This can be done automatically through routing rules or manually by a dispatcher. This activity is captured by tracking the initial population of the 'Group' field in the incident's audit log.
Why it matters Tracking assignments is key to measuring first-response times and identifying bottlenecks in the dispatching process. It helps analyze how efficiently incidents are routed to the correct team. Where to get Inferred from the first entry in the incident's activity log that populates or changes the 'Group' field. Capture Identify the first timestamp where the 'Group' field is populated for an incident. Event type inferred
	Incident Closed	Represents the final, formal closure of the incident record. This typically happens automatically after a set period in the 'Resolved' state, or can be done manually by an agent. This event marks the end of the incident lifecycle.
Why it matters This activity is the definitive end point of the process. The total time to this event represents the full incident lifecycle duration, including any user confirmation periods. Where to get Inferred from the incident's activity log by identifying when the 'Status' field is updated to 'Closed'. Capture Use the timestamp from the activity log entry for the status change to 'Closed'. Event type inferred
	Incident Prioritized	Occurs when the priority of the incident is set or updated. The priority level dictates the urgency and SLA targets for resolution. This is captured by monitoring changes to the 'Priority' field within the incident's history.
Why it matters Incorrect or delayed prioritization can lead to SLA breaches and inefficient resource allocation. Analyzing this activity helps ensure critical incidents receive immediate attention. Where to get Inferred from the incident's activity log, which tracks all updates to the 'Priority' field. Capture Use timestamps from the audit log where the 'Priority' field value was set or changed. Event type inferred
	Incident Reported	Marks the creation of a new incident record in Freshservice. This is the starting point of the incident lifecycle, typically triggered by an end-user via a portal, email, or a service desk agent creating a ticket on their behalf. This event is explicitly logged with a creation timestamp.
Why it matters This activity is the primary start event for the entire process. Analyzing the time from this event to resolution is fundamental for measuring overall cycle times and SLA adherence. Where to get Captured from the incident table's creation timestamp. Freshservice logs this explicitly for every new ticket. Capture Use the 'Created at' timestamp from the main incident record. Event type explicit
	Incident Resolved	Marks the point where the agent has implemented a fix and considers the incident resolved. This is captured when the incident's status is changed to 'Resolved'. In Freshservice, this is a key milestone that stops the SLA clock.
Why it matters This is a critical milestone for measuring Time to Resolution (TTR). The period between 'Resolved' and 'Closed' is important for analyzing user confirmation delays and auto-closure policies. Where to get Inferred from the incident's activity log by identifying when the 'Status' field is updated to 'Resolved'. Capture Use the timestamp from the activity log entry for the status change to 'Resolved'. Event type inferred
	Resolution Note Added	Occurs when an agent documents the solution to the incident by adding a resolution note. This is a distinct action in Freshservice before changing the status to 'Resolved'. This action and its content are explicitly logged.
Why it matters This marks the identification of a solution. The time between this and the 'Incident Resolved' status can indicate internal review or documentation overhead. Where to get Captured from the timestamp when a resolution note is added to the incident, which is logged in the conversation history. Capture Identify the timestamp of the 'Resolution Note' entry in the incident's conversation log. Event type explicit
	Status Changed to In Progress	This activity marks the official start of active investigation and work on the incident. It is captured when an agent changes the incident's status to 'In Progress'. This is a standard status change logged in the ticket's activity history.
Why it matters This milestone helps differentiate between waiting time and active work time. Analyzing the duration an incident stays 'In Progress' is key to understanding resolution effort. Where to get Inferred from the incident's activity log by identifying when the 'Status' field is updated to 'In Progress'. Capture Filter the activity log for a status change to 'In Progress' and use its timestamp. Event type inferred
	Agent Assigned to Incident	This activity marks when a specific agent is assigned to handle the incident. It signifies individual ownership of the ticket. The assignment is logged in the ticket's activity history, showing which agent was assigned and when.
Why it matters This allows for analysis of agent workload, performance, and the time it takes for an incident to be picked up by an individual after group assignment. It is crucial for agent performance dashboards. Where to get Tracked through changes to the 'Agent' field in the incident's activity log or audit trail. Capture Identify timestamps corresponding to changes in the 'Agent' field. Event type inferred
	First Response Sent	This activity represents the first communication from an agent to the user after the incident was reported. It can be a public note or a direct reply. Freshservice logs all agent communications with timestamps.
Why it matters Meeting First Response SLA is a critical KPI for customer satisfaction. This activity allows for the measurement and analysis of how quickly agents engage with new incidents. Where to get Identified by finding the timestamp of the first public note or reply added by an agent in the incident's conversation log. Capture Filter the incident's conversation history for the earliest entry made by an agent. Event type explicit
	Incident Reassigned	Indicates that the incident was transferred from one agent or group to another. This signifies a handoff in the resolution process. This event is inferred by detecting subsequent changes to the 'Agent' or 'Group' fields after the initial assignment.
Why it matters Frequent reassignments, or handoffs, often indicate process inefficiencies, knowledge gaps, or incorrect initial routing. Analyzing these events helps identify and reduce delays. Where to get Inferred from the incident's activity log by tracking any change to the 'Agent' or 'Group' fields after the first assignment. Capture Detect changes in the 'Agent' or 'Group' fields in the ticket's audit history. Event type inferred
	Incident Reopened	Occurs when an incident that was previously marked as 'Resolved' is returned to an open status, typically by the user disagreeing with the resolution. This is inferred by a status change from 'Resolved' back to a state like 'Open' or 'In Progress'.
Why it matters A high reopening rate points to issues with resolution quality or incomplete fixes. This is a key metric for analyzing rework and agent performance. Where to get Inferred from the incident's activity log by detecting a status change from 'Resolved' to an active status. Capture Filter the activity log for a 'Status' change from 'Resolved' to 'Open' or 'In Progress'. Event type inferred
	SLA Target Breached	This is a calculated event that occurs when the time elapsed on an incident exceeds its defined SLA target for response or resolution. Freshservice tracks SLA status internally and this event can be derived by comparing timestamps against SLA policies.
Why it matters Directly measures compliance with service level commitments. Identifying when and why breaches occur is essential for the SLA Performance Dashboard and continuous improvement. Where to get Calculated by comparing the resolution or response timestamp with the SLA target due time. Freshservice often flags tickets as 'SLA Violated'. Capture Derive by comparing the 'Resolved at' timestamp to the 'Due by' timestamp, or when the 'SLA Status' field changes to 'Violated'. Event type calculated
	Status Changed to Pending	Represents a point where the resolution process is paused, typically while waiting for information from the user or a third party. This is inferred from a status change to any 'Pending' state. The time spent in this state is often excluded from SLA calculations.
Why it matters Identifying time spent in pending states is crucial for understanding external dependencies and delays. It helps isolate agent work time from waiting time. Where to get Inferred from the incident's activity log when the 'Status' field is updated to a value such as 'Pending' or 'Awaiting User Response'. Capture Filter the activity log for status changes to any pending state and use the associated timestamp. Event type inferred
	Workaround Provided	This activity signifies that a temporary solution or workaround has been communicated to the user to mitigate the incident's impact. Capturing this often requires specific system configuration, such as a dedicated checkbox, a specific note type, or keyword analysis in agent notes.
Why it matters This helps analyze the effectiveness of workarounds in reducing business impact and their relationship to the final resolution time. It supports the Workaround Effectiveness Metrics dashboard. Where to get This is likely not an explicit event. It may be inferred by flagging notes containing keywords like 'workaround', or if a custom 'Workaround Provided' checkbox field is used and its change is logged. Capture Inferred from a custom field change or keyword analysis of agent notes. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Freshservice

Steps

Access Freshservice Analytics: Log in to your Freshservice instance with an account that has permissions to access and create reports. Navigate to the Analytics module from the main menu.
Create a New Report: Click on the New Report button. Provide a descriptive name, such as "Incident Management Event Log". Select the Incident Management module when prompted to choose a data source.
Select Report Widget: Inside the report editor, add a new widget and select the Table type. This will form the basis of your event log data.
Add Primary Data Columns: From the data source panel on the right, drag and drop the necessary fields into the table's column configuration. Start with Incident ID, Created at, Agent, Group, Priority, Severity, Status, and Category.
Incorporate Activity Data: To capture individual events, you must join or include data from the ticket activities. Add the Activities data source to your widget. From this source, add Performed at (for the event timestamp) and Activity description or similar fields that describe the change that occurred.
Create a Calculated 'ActivityName' Column: This is the most critical step. Create a new calculated column or formula field. Use nested IF statements or a CASE function to translate raw activity data into the required ActivityName values. See the Query section for the detailed logic for each of the 14 activities.
Configure the 'EventTimestamp': Create another calculated column for the EventTimestamp. The logic for this column should select the Created at timestamp for the 'Incident Reported' activity and the activity's Performed at timestamp for all other events.
Apply Report Filters: Configure the report filters to narrow down the data. At a minimum, set a date range filter on the 'Created at' field. A range of the last 3 to 6 months is recommended. You should also add a filter to include only tickets where 'Ticket Type' is 'Incident'.
Run and Refine the Report: Run the report to generate a preview of the data. Review the output to ensure the ActivityName and EventTimestamp columns are being populated correctly. Adjust formulas and filters as needed.
Save and Export the Report: Once you are satisfied with the report's output, save it. Use the Export option and select CSV as the format.
Schedule the Export (Optional): For ongoing analysis, you can schedule the report to run and export automatically. Set up a schedule (e.g., daily or weekly) to have the CSV delivered to your email or another destination.
Prepare Data for Upload: Open the exported CSV file. Rename the column headers to match the required schema for ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Add the static columns SourceSystem (with the value 'Freshservice') and LastDataUpdate (with the current timestamp). The file is now ready for upload.

Configuration

Analytics Module: This extraction requires access to the Freshservice Analytics module, which is available in higher-tier plans (e.g., Pro, Enterprise).
Required Permissions: Your user account needs a role with permissions to create, edit, and run reports in the Analytics module.
Date Range: It is crucial to set a date range filter on the incident creation date to manage the data volume. A rolling 3-6 month period is recommended for a balance of historical context and performance.
Report Filters: Always filter for 'Ticket Type' equals 'Incident' to exclude service requests or other ticket types from your process analysis.
Calculated Fields: The method relies heavily on the use of calculated fields (formulas) to derive the ActivityName and EventTimestamp for each event. Familiarity with the Freshservice formula editor is beneficial.
Data Volume: Be aware that for every incident, this extraction generates multiple rows (one for each activity). For large Freshservice instances, the resulting CSV file can become very large, impacting report generation time and export speed.

a Sample Query config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Steps

Prerequisites: Ensure you have Python 3.6+ installed along with the requests and pandas libraries. You can install them using pip: pip install requests pandas.
Generate API Key: Log in to your Freshservice instance as an administrator. Navigate to your Profile Settings by clicking your profile picture in the top-right corner. Go to the 'API Key' section and copy your personal API key. Treat this key like a password.
Set Up Script: Save the provided Python code into a file named extract_freshservice_incidents.py on your local machine.
Configure Parameters: Open the script file in a text editor. Update the placeholder values for FRESHSERVICE_DOMAIN (e.g., 'yourcompany.freshservice.com'), API_KEY (the key you just copied), and START_DATE_STR (the beginning of your desired extraction period in 'YYYY-MM-DD' format).
Understand Script Logic: The script first fetches all incident tickets created after the specified start date. It iterates through each page of results returned by the API. For each ticket, it makes a second API call to retrieve its detailed activity history.
Event Log Generation: The script processes the core ticket data and its activity log to identify and create records for each of the 14 required business activities. For example, 'Incident Reported' is created from the ticket's creation date, while 'Status Changed to In Progress' is derived from a specific entry in the activity log.
Derive Complex Events: Events like 'SLA Target Breached' are derived. The script checks if a ticket's resolution SLA was violated. If so, it creates an event timestamped with the due_by date, marking the moment the breach occurred.
Execute the Script: Open a terminal or command prompt, navigate to the directory where you saved the script, and run it using the command: python extract_freshservice_incidents.py.
Monitor Execution: The script will print progress updates to the console, showing how many tickets have been processed. Depending on the number of tickets and API rate limits, this may take some time.
Review the Output: Once the script finishes, it will generate a CSV file named freshservice_incident_event_log.csv in the same directory. This file contains the complete event log.
Prepare for Upload: Open the CSV file in a spreadsheet program to ensure the columns (IncidentId, ActivityName, EventTimestamp, etc.) are populated as expected. The file is now ready for upload into ProcessMind or another process mining tool.

Configuration

FRESHSERVICE_DOMAIN: Your company's specific Freshservice URL, for example, mycompany.freshservice.com. This is a required parameter in the script.
API_KEY: The personal API key for a user with sufficient permissions to read all incident data. This is a required parameter.
START_DATE_STR: The start date for the data extraction in 'YYYY-MM-DD' format. It is recommended to extract an initial period of 3-6 months of data for meaningful analysis.
PAGE_SIZE: Set to 100, the maximum allowed by the Freshservice API, to minimize the number of API calls and improve performance. It is generally not recommended to change this value.
API Rate Limiting: The script includes a basic time.sleep(1) call after processing each ticket to respect Freshservice's API rate limits. For high-volume instances, this may need to be adjusted to avoid errors.
Required Permissions: The API key used must belong to a user account (e.g., a dedicated service account) with at least 'SD Agent' role permissions to ensure it can access all necessary ticket fields and activity logs across different service desk groups.

a Sample Query python

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

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

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

Steps

Access Freshservice Analytics: Log in to your Freshservice instance with an account that has permissions to access and create reports. Navigate to the Analytics module from the main menu.
Create a New Report: Click on the New Report button. Provide a descriptive name, such as "Incident Management Event Log". Select the Incident Management module when prompted to choose a data source.
Select Report Widget: Inside the report editor, add a new widget and select the Table type. This will form the basis of your event log data.
Add Primary Data Columns: From the data source panel on the right, drag and drop the necessary fields into the table's column configuration. Start with Incident ID, Created at, Agent, Group, Priority, Severity, Status, and Category.
Incorporate Activity Data: To capture individual events, you must join or include data from the ticket activities. Add the Activities data source to your widget. From this source, add Performed at (for the event timestamp) and Activity description or similar fields that describe the change that occurred.
Create a Calculated 'ActivityName' Column: This is the most critical step. Create a new calculated column or formula field. Use nested IF statements or a CASE function to translate raw activity data into the required ActivityName values. See the Query section for the detailed logic for each of the 14 activities.
Configure the 'EventTimestamp': Create another calculated column for the EventTimestamp. The logic for this column should select the Created at timestamp for the 'Incident Reported' activity and the activity's Performed at timestamp for all other events.
Apply Report Filters: Configure the report filters to narrow down the data. At a minimum, set a date range filter on the 'Created at' field. A range of the last 3 to 6 months is recommended. You should also add a filter to include only tickets where 'Ticket Type' is 'Incident'.
Run and Refine the Report: Run the report to generate a preview of the data. Review the output to ensure the ActivityName and EventTimestamp columns are being populated correctly. Adjust formulas and filters as needed.
Save and Export the Report: Once you are satisfied with the report's output, save it. Use the Export option and select CSV as the format.
Schedule the Export (Optional): For ongoing analysis, you can schedule the report to run and export automatically. Set up a schedule (e.g., daily or weekly) to have the CSV delivered to your email or another destination.
Prepare Data for Upload: Open the exported CSV file. Rename the column headers to match the required schema for ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup, etc. Add the static columns SourceSystem (with the value 'Freshservice') and LastDataUpdate (with the current timestamp). The file is now ready for upload.

Configuration

Analytics Module: This extraction requires access to the Freshservice Analytics module, which is available in higher-tier plans (e.g., Pro, Enterprise).
Required Permissions: Your user account needs a role with permissions to create, edit, and run reports in the Analytics module.
Date Range: It is crucial to set a date range filter on the incident creation date to manage the data volume. A rolling 3-6 month period is recommended for a balance of historical context and performance.
Report Filters: Always filter for 'Ticket Type' equals 'Incident' to exclude service requests or other ticket types from your process analysis.
Calculated Fields: The method relies heavily on the use of calculated fields (formulas) to derive the ActivityName and EventTimestamp for each event. Familiarity with the Freshservice formula editor is beneficial.
Data Volume: Be aware that for every incident, this extraction generates multiple rows (one for each activity). For large Freshservice instances, the resulting CSV file can become very large, impacting report generation time and export speed.

a Sample Query config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Data Template: Incident Management

Your Incident Management Data Template

Incident Management Attributes

Incident Management Activities

Extraction Guides

Freshservice Analytics Module Data Export to CSV

Steps

Configuration

a Sample Query config

Python Script Extraction via Freshservice REST API

Steps

Configuration

a Sample Query python

Real-time Data Push via Workflow Automator Webhooks

Steps

Configuration

a Sample Query config

Ready to Get Started?

Stop SLA Breaches: Optimize Incident Management Today