> Continuous Process Improvement > Incident Management > Zendesk Support > Data Template

Your Incident Management Data Template

Zendesk Support

Incident Management Attributes (24) Incident Management Activities (13) Extraction Guides (4)

Your Incident Management Data Template

This template provides a structured overview of the essential data required to effectively analyze your incident management process. It outlines key attributes to collect, critical activities to track, and includes practical guidance for extracting this data from Zendesk Support. Use it to ensure your process mining project starts with a robust and complete dataset.

Recommended attributes to collect
Key activities to track for process mapping
Practical data 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 a thorough analysis of your incident management process.

5 Required 7 Recommended 12 Optional

	Name	Description
	Event Timestamp EventTimestamp	The exact date and time when the activity occurred.
Description This timestamp records the precise moment an event happened in the incident lifecycle, such as when a comment was added or the status was changed. It provides the chronological order for all activities within a case. This attribute is fundamental for any time-based process mining analysis. It is used to calculate cycle times between activities, identify waiting times, measure overall case duration, and analyze process performance over different time periods. Accurate timestamps are essential for creating an animated process map that shows the flow of cases over time and for building performance dashboards that track KPIs like average resolution time. Why it matters Timestamps provide the chronological context for all activities, enabling the calculation of durations, the identification of bottlenecks, and the analysis of process performance over time. Where to get Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), field created_at for each audit event. Examples 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	Incident ID TicketId	The unique system-generated identifier for each incident ticket.
Description The Incident ID is the primary key that uniquely identifies each incident case within Zendesk Support. It serves as the CaseId for process mining, linking all related activities, status changes, and communications from the moment the incident is created until it is closed. In analysis, this ID is crucial for reconstructing the end-to-end journey of every incident. It allows for the aggregation of event data to track metrics like total resolution time, number of handoffs, and adherence to service level agreements for individual cases. By grouping events by this ID, analysts can visualize process flows, identify common pathways, and detect deviations from the standard procedure. Why it matters This is the essential identifier that connects all events to a single incident, making it possible to trace the entire lifecycle and analyze process performance accurately. Where to get Zendesk Tickets API (/api/v2/tickets/{id}), field id. Examples 19428230113521941055
	Activity ActivityName	The name of the business activity or event that occurred at a specific point in the incident lifecycle.
Description This attribute describes a specific step or action taken within the incident management process, such as 'Incident Created', 'Ticket Assigned to Agent', or 'Incident Resolved'. These activities are derived from the event log or audit trail data from Zendesk, where system changes are recorded. In process mining, the sequence of these activities forms the process map, which is the foundation for all analysis. By analyzing the flow of activities, organizations can discover the actual paths incidents take, identify bottlenecks between steps, measure rework loops (e.g., re-opening a resolved ticket), and check for conformance against a defined standard process. Why it matters The sequence of activities defines the process flow, which is the core of process mining analysis for identifying inefficiencies, deviations, and improvement opportunities. Where to get Derived from events in the Zendesk Ticket Audits API. For example, a Change event on the status field could be mapped to 'Status Changed'. Examples Incident CreatedTicket Assigned to AgentStatus Changed to PendingIncident ResolvedIncident Closed
	Last Data Update LastDataUpdate	The timestamp indicating when the data for this process was last refreshed.
Description This attribute records the date and time of the most recent data extraction or update from the source system. It is typically a single value applied to the entire dataset from a given refresh cycle. This information is vital for data governance and for users of the process mining analysis. It provides context on the freshness of the data, helping analysts understand if they are viewing the most current information available. This is particularly important for monitoring operational performance and making timely decisions based on the analysis. Why it matters Provides crucial context on data freshness, ensuring that users understand how current the analysis is and when the data was last sourced. Where to get Timestamp generated by the ETL/data pipeline process upon completion of the data refresh. Examples 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Source System SourceSystem	The system from which the incident data was extracted.
Description This attribute identifies the origin of the process data. For this view, the value would be static, for example, 'Zendesk Support', indicating that all events and attributes were sourced from that system. In environments where data from multiple systems is combined, this field is critical for distinguishing between different data sources. It helps ensure data integrity and allows for source-specific analysis, such as comparing the incident management process in Zendesk with another ITSM tool. Why it matters Identifies the data's origin, which is crucial for data governance and for analyses that combine data from multiple source systems. Where to get Static value set during data transformation to identify the data origin. Examples Zendesk SupportZendesk
	Assigned Agent Assignee	The individual support agent currently assigned to handle the incident.
Description This attribute identifies the specific agent responsible for the incident at a given time. Changes in the assignee are critical events that signify a handoff of work from one person to another. Analyzing the assigned agent helps in understanding workload distribution, individual performance, and collaboration patterns. Tracking changes in this field is essential for calculating the 'Average Handoffs per Incident' KPI and identifying situations where incidents are passed around frequently, which can indicate knowledge gaps or inefficient routing. Why it matters Identifies the responsible agent, enabling workload analysis and the tracking of handoffs, which is crucial for identifying process inefficiencies. Where to get Zendesk Tickets API, field assignee_id. Changes are logged in the Ticket Audits API. Examples John SmithJane DoeService Desk Automation
	Assigned Group AssignedGroup	The support team or group currently assigned to the incident.
Description This attribute indicates which team is responsible for the incident. Incidents often move between different support tiers or specialized groups, for example, from 'L1 Support' to the 'Network Team'. This is a critical dimension for analyzing process handoffs and identifying bottlenecks. By monitoring how incidents flow between groups, analysts can measure inter-team dependencies, calculate queue times for specific teams, and optimize routing rules. It directly supports the 'Handoffs and Rework Analysis' dashboard. Why it matters Tracks team ownership, which is essential for analyzing inter-team handoffs, identifying team-specific bottlenecks, and measuring queue times. Where to get Zendesk Tickets API, field group_id. Changes are logged in the Ticket Audits API. Examples L1 SupportL2 Network TeamL3 InfrastructureBilling
	Event End Time EventEndTime	The timestamp indicating when an activity was completed.
Description The Event End Time marks the conclusion of an activity. In event log data, the end time of one activity is often inferred as the start time of the next activity in the sequence for that case. For the very last activity in a case, the end time might be the same as its start time. This attribute is essential for calculating the duration of individual activities (ProcessingTime) and the waiting time between activities. This information is the foundation for bottleneck analysis, allowing analysts to see not just how long a step takes, but also how long the case was idle before that step began. Why it matters Enables the calculation of activity durations and waiting times, which is fundamental for performing detailed bottleneck analysis and identifying process delays. Where to get Calculated as the start time of the subsequent event within the same case. The last event's end time can be the same as its start time or the case closure time. Examples 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Priority TicketPriority	The priority level assigned to the incident, such as 'Low', 'Normal', 'High', or 'Urgent'.
Description The priority of an incident determines the required urgency for a response and resolution. It is a key factor in work prioritization and resource allocation within the support team. In process analysis, priority is used to segment incidents to compare their process flows and performance. For example, analysts can check if 'Urgent' incidents are actually resolved faster than 'Low' priority ones. It is also used to monitor SLA compliance, as SLAs are often defined based on priority levels. The 'Priority Change Rate' KPI relies on tracking changes to this field. Why it matters This attribute is crucial for segmenting analysis, evaluating prioritization effectiveness, and monitoring SLA compliance for different urgency levels. Where to get Zendesk Tickets API, field priority. Changes are logged in the Ticket Audits API. Examples lownormalhighurgent
	Reporting Channel Channel	The channel through which the incident was initially reported, such as 'Email', 'Web', or 'API'.
Description This attribute captures the method used by the end-user or system to create the incident ticket. Understanding the channel is important for analyzing incident sources and tailoring the support process accordingly. Analyzing incidents by channel can reveal different patterns. For example, incidents reported via phone might have shorter resolution times compared to those from email. This information supports the 'Incident Throughput Volume' dashboard and helps in resource planning and channel optimization efforts. Why it matters Helps analyze incident volumes and process performance by source, enabling channel-specific process improvements and resource allocation. Where to get Zendesk Tickets API, field via.channel. Examples webemailapiphone
	SLA Status SlaStatus	The current status of the Service Level Agreement (SLA) for the incident.
Description This attribute indicates whether an incident is on track to meet its defined SLA targets, has already breached them, or if the SLA timers are paused. Zendesk automatically tracks SLA metrics based on configured policies. This is a critical attribute for the 'SLA Compliance Monitoring' dashboard. It provides a direct measure of performance against service commitments. By analyzing when and why SLAs are breached, organizations can identify process weaknesses and improve service reliability. It directly supports the 'Incident SLA Adherence Rate' KPI. Why it matters Directly measures performance against service commitments, enabling analysis of SLA breaches and proactive monitoring to improve compliance. Where to get Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), derived from fields like sla_policy, breached_at, etc. Examples ActivePausedBreachedFulfilled
	Ticket Status TicketStatus	The status of the incident ticket at the time of the event, such as 'Open', 'Pending', or 'Solved'.
Description This attribute reflects the state of the incident ticket at different points in its lifecycle. Standard Zendesk statuses include new, open, pending, on-hold, solved, and closed. Tracking changes to this field is a primary way to generate activities for process mining. Analyzing the ticket status is fundamental to understanding the process. It helps identify how much time incidents spend in certain states, such as 'Pending', which often indicates waiting on customer response. It is also key to defining case completion and calculating resolution times. Why it matters Tracking status changes is key to understanding process progression, identifying wait times, and defining the start and end points of the incident lifecycle. Where to get Zendesk Tickets API, field status. Changes are logged in the Ticket Audits API. Examples newopenpendingsolvedclosed
	Case Duration CaseDuration	The total time elapsed from the creation of the incident to its final closure.
Description This calculated metric represents the end-to-end cycle time for a single incident. It is computed by taking the difference between the timestamp of the very first event (e.g., 'Incident Created') and the very last event (e.g., 'Incident Closed'). Case Duration is a primary Key Performance Indicator (KPI) for overall process efficiency. It is heavily used in dashboards to show average cycle times, identify long-running cases, and analyze trends over time. It provides a high-level measure of how quickly the process can handle and resolve incidents. Why it matters This is a critical KPI for measuring overall process velocity and identifying factors that contribute to long resolution times. Where to get Calculated by finding the difference between the timestamp of the last event and the first event for each Incident ID. Examples 25920060480086400
	Customer Organization Organization	The organization or company to which the incident requester belongs.
Description This attribute links an incident to the customer's organization. It is essential for B2B support environments where service levels and support processes may vary by customer. Analyzing incidents by organization allows support teams to monitor customer health, identify recurring issues affecting specific clients, and ensure contractual obligations are being met. It is a key dimension for filtering dashboards and reports to provide a customer-centric view of performance. Why it matters Enables customer-specific analysis, helping to monitor service levels, identify trends for key accounts, and manage customer relationships effectively. Where to get Zendesk Tickets API, field organization_id. Examples Global Tech Inc.Innovate SolutionsData Corp
	Handoff Count HandoffCount	The total number of times an incident was reassigned to a different agent or group.
Description This calculated metric quantifies the number of times responsibility for an incident was transferred. Each change in the Assignee or AssignedGroup field increments this count for the case. Handoffs are a common source of inefficiency and delay in incident management. A high handoff count can indicate unclear routing rules, knowledge gaps in support teams, or overly complex processes. This metric is the basis for the 'Average Handoffs per Incident' KPI and is crucial for the 'Handoffs and Rework Analysis' dashboard. Why it matters Quantifies process friction caused by transfers, helping to pinpoint routing inefficiencies and knowledge gaps that prolong resolution times. Where to get Calculated by counting the number of times the AssignedGroup or Assignee field changed for an incident. Examples 0135
	Is Automated IsAutomated	A boolean flag indicating if an activity was performed by an automated system or a human agent.
Description This derived attribute helps distinguish between events executed by human users and those performed by system automations, triggers, or API integrations. It is typically determined by checking if the author of an event is a known system user. Understanding the level of automation is crucial for modern process analysis. It helps in evaluating the effectiveness of automation rules, identifying manual tasks that could be automated, and measuring the impact of automation on efficiency and resolution times. This attribute can be used to compare the process flows of automated versus manual activities. Why it matters Distinguishes between human and system actions, which is essential for analyzing the impact of automation on process efficiency and identifying new automation opportunities. Where to get Derived by checking if the event author (author_id in the Ticket Audits API) corresponds to a known system or automation user. Examples truefalse
	Is First Contact Resolution IsFirstContactResolution	A boolean flag that is true if the incident was resolved by the first assigned agent or group without any handoffs.
Description First Contact Resolution (FCR) is a critical metric for support center efficiency and customer satisfaction. This calculated attribute flags incidents that were resolved without being reassigned to another agent or team. The logic typically checks if the ticket reached a 'Solved' status while still being assigned to the initial agent and group. In process mining, this allows for the direct calculation of the FCR rate and for comparing the process paths of FCR incidents versus those that required escalation, helping to identify opportunities to empower front-line support. Why it matters Directly measures the efficiency of the initial support touchpoint and helps identify opportunities to shift resolution earlier in the process. Where to get Calculated boolean flag. True if the ticket status is 'solved' or 'closed' and there was only one unique assignee or assigned group throughout the incident's lifecycle. Examples truefalse
	Processing Time ProcessingTime	The duration of a single activity, representing the time spent actively working on a task.
Description This metric measures the time elapsed from the start of an activity to its end. It is calculated as the difference between the EventEndTime and the EventTimestamp for each row in the event log. Processing time, also known as activity duration, helps differentiate between active work time and idle or waiting time. In the 'Bottleneck Activities Overview' dashboard, high average processing times for certain activities can indicate complex, time-consuming tasks. This is distinct from waiting time, which represents delays between tasks. Why it matters Measures active work time for specific activities, helping to identify tasks that are inherently time-consuming and are candidates for simplification or automation. Where to get Calculated as the difference between EventEndTime and EventTimestamp for each activity. Examples 30018003600
	Root Cause Category RootCauseCategory	The high-level category of the underlying root cause of the incident.
Description This attribute is used to classify the fundamental reason why an incident occurred. It is typically captured towards the end of the incident lifecycle, often as part of a post-mortem or problem management process, and stored in a custom field. This data is essential for the 'Root Cause Identification Accuracy' dashboard and the 'RCA Coverage' KPI. Analyzing incidents by root cause helps identify recurring problems, guiding efforts to implement permanent fixes and reduce future incident volume. It shifts the focus from reactive firefighting to proactive problem prevention. Why it matters Enables proactive problem management by categorizing incident causes, helping to identify trends and prevent future occurrences. Where to get This is typically a custom ticket field. Check Ticket Fields configuration in Zendesk Admin Center. Examples Software BugHardware FailureUser ErrorNetwork Outage
	Satisfaction Rating SatisfactionRating	The satisfaction rating provided by the end-user after the incident was resolved.
Description This attribute captures the customer's feedback on their support experience, typically collected via a survey after the ticket is solved. Common ratings in Zendesk are 'Good' or 'Bad'. While not a direct measure of process efficiency, satisfaction ratings provide a critical outcome metric. In process mining, this can be correlated with process variants to understand which resolution paths lead to higher customer satisfaction. For example, do incidents with more handoffs receive lower ratings? Why it matters Provides a key outcome metric that can be correlated with process characteristics to understand how process performance impacts user satisfaction. Where to get Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), field satisfaction_rating.score. Examples goodbadofferedunoffered
	Severity Severity	The level of impact the incident has on the business.
Description Severity defines the business impact of an incident, often in conjunction with priority to determine the overall urgency. It is typically configured as a custom field in Zendesk. Analyzing severity helps in understanding the criticality of incidents being handled. It is a key dimension for segmenting data in dashboards like 'SLA Compliance Monitoring' and 'Prioritization Effectiveness Metrics'. Comparing process flows for different severity levels can reveal if high-severity incidents are being handled with the appropriate speed and resources. Why it matters Indicates the business impact of an incident, allowing for analysis focused on the most critical issues and ensuring they are resolved efficiently. Where to get This is typically a custom field. Check Ticket Fields configuration in Zendesk Admin Center. Examples 1 - Critical2 - High3 - Medium4 - Low
	Submitter Submitter	The end-user or system that originally reported the incident.
Description This attribute identifies the person or entity that created the ticket. This is distinct from the requester, as an agent might create a ticket on behalf of someone else. In analysis, the submitter can be used to understand who is reporting issues. When combined with organization data, it can help identify if specific customers or user groups are experiencing a high volume of incidents. This can guide proactive support initiatives or training efforts. Why it matters Identifies the source of the incident report, which can be analyzed to find patterns related to specific users, departments, or automated systems. Where to get Zendesk Tickets API, field submitter_id. Examples alice.jones@example.combob.williams@example.comSystem Monitor
	Tags Tags	A list of tags applied to the incident for categorization and context.
Description Tags are flexible labels that can be added to tickets to provide additional context or aid in categorization and routing. They can be added manually by agents or automatically via triggers and automations. Tags are a rich source of data for process mining analysis. They can be used to create fine-grained segments for analysis, such as filtering for incidents related to a specific product launch ('launch_q4') or a known outage ('outage_20231027'). This flexibility allows for deep-dive investigations that go beyond standard ticket fields. Why it matters Offers a flexible way to categorize and filter incidents, enabling detailed, context-specific analysis that may not be possible with standard fields alone. Where to get Zendesk Tickets API, field tags. Examples vip_usernetwork_issueoutage_20231027billing_related
	Ticket Type TicketType	The classification of the ticket, such as 'Incident', 'Problem', 'Question', or 'Task'.
Description This field categorizes the ticket based on the nature of the request. The incident management process specifically focuses on tickets where the type is 'Incident', representing an unplanned interruption or reduction in quality of an IT service. In analysis, this attribute is primarily used as a filter to ensure that only incidents are included in the process view. It can also be used for broader ITSM analysis to compare the processes for handling incidents versus problems or service requests. Why it matters Allows for the filtering of data to focus specifically on incidents, ensuring the process analysis is relevant to the incident management lifecycle. Where to get Zendesk Tickets API, field type. Examples incidentproblemquestiontask

Required Recommended Optional

Incident Management Activities

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

6 Recommended 7 Optional

	Activity	Description
	Incident Closed	Marks the final end of the incident lifecycle when the ticket is permanently closed. In Zendesk, this often happens automatically after a set period of time from being solved, and is captured as a final status change.
Why it matters This is the definitive end activity for the process. The total process duration is calculated from 'Incident Created' to this event, providing an end-to-end view of the cycle time. Where to get Captured from the ticket audit log via a 'Change' event where the 'status' field's new value becomes 'closed'. Capture Identified by a 'Change' event for the 'status' field to 'closed'. Event type explicit
	Incident Created	Marks the beginning of the incident lifecycle when a new ticket is created in Zendesk. This event is captured explicitly through Zendesk's ticket creation audit log, serving as the starting point for every case.
Why it matters This is the primary start activity. Analyzing the time from this event to others is crucial for measuring overall ticket lifecycle duration and initial response times. Where to get This is an explicit event captured in the Zendesk ticket audit logs. Every new ticket generates a 'Create' event with a corresponding timestamp. Capture Directly from the ticket creation event in the audit log. Event type explicit
	Incident Resolved	This key milestone occurs when an agent has implemented a solution and marks the ticket as 'solved'. This is an explicit action, captured as a status change in the ticket audit log.
Why it matters This is the primary resolution activity and a critical point for measuring time-to-resolution. The time between this event and 'Incident Closed' represents the user confirmation or auto-closure period. Where to get Captured from the ticket audit log via a 'Change' event where the 'status' field's new value becomes 'solved'. Capture Identified by a 'Change' event for the 'status' field to 'solved'. Event type explicit
	Status Changed to Open	Indicates that an agent has started actively working on the incident. This activity is typically inferred from the ticket 'status' field changing from 'new' to 'open', signifying the start of the investigation and diagnosis phase.
Why it matters This event marks the transition from queuing to active work. The duration tickets spend in 'new' status before moving to 'open' is a key metric for initial response time. Where to get Inferred from the ticket audit log by identifying a 'Change' event where the 'status' field's new value is 'open' and the previous value was 'new'. Capture Inferred from a status field change from 'new' to 'open'. Event type inferred
	Ticket Assigned to Agent	This activity occurs when a ticket is assigned to a specific agent for handling. This is an explicit event logged in the ticket's audit history and signifies that an individual has taken ownership.
Why it matters This milestone is essential for measuring time to first assignment and is the basis for analyzing handoffs, rework, and First Contact Resolution rates. Where to get Captured from the ticket audit log when the 'assignee_id' field is populated or changed. The first assignment is a key milestone for KPI calculation. Capture Identified by a 'Change' event for the 'assignee_id' field in the ticket audit log. Event type explicit
	Ticket Reassigned	Occurs when ticket ownership is transferred from one agent or group to another after the initial assignment. This is an explicit event tracked in the ticket's audit history.
Why it matters Reassignments are critical for analyzing handoffs and rework. A high frequency of reassignments often points to incorrect initial routing, complex issues, or process bottlenecks. Where to get Captured from the ticket audit log by identifying a 'Change' event on the 'assignee_id' or 'group_id' field after it was first populated. Capture Identified by a subsequent 'Change' event for the 'assignee_id' or 'group_id' field. Event type explicit
	Internal Note Added	This activity signifies internal collaboration, where an agent adds a private note to the ticket for other team members. This is captured explicitly when a comment is marked as not public.
Why it matters Analyzing internal notes can provide insights into complex issues that require collaboration, but an excessive number may indicate knowledge gaps or process inefficiencies. Where to get Captured from the ticket comments data. A comment is identified as an internal note when its 'public' attribute is false. Capture Event logged when a new comment with 'public: false' is added to the ticket. Event type explicit
	Priority Set	An incident's priority level (e.g., Low, Normal, High, Urgent) is defined. This is recorded as an explicit change event and dictates the urgency and required response time for the ticket.
Why it matters Tracking when and how priority is set is vital for the 'Prioritization Effectiveness Metrics' dashboard, ensuring critical issues are addressed promptly. Where to get Captured from a 'Change' event on the 'priority' field within the ticket audit log. Subsequent changes can also be tracked to measure the Priority Change Rate KPI. Capture Identified by a 'Change' event for the 'priority' field in the ticket audit log. Event type explicit
	Public Reply Sent	Represents a communication sent from a support agent to the end-user. This is an explicit event in Zendesk, captured whenever a public comment is added to the ticket.
Why it matters Tracking public replies is important for understanding communication frequency and can be a key part of the timeline when analyzing user confirmation delays. Where to get Captured from the ticket comments data. A comment is identified as public when its 'public' attribute is true. Capture Event logged when a new comment with 'public: true' is added to the ticket. Event type explicit
	SLA Target Breached	Marks the moment a ticket has failed to meet a defined Service Level Agreement, such as first reply time or resolution time. This event is calculated based on SLA policy definitions and ticket update timestamps.
Why it matters This event directly supports SLA compliance monitoring. Identifying when and why breaches occur is fundamental to improving service reliability and customer trust. Where to get This is a calculated event. It can be derived by analyzing the 'sla_policy_metrics' data associated with a ticket, using the 'breached_at' timestamp for each SLA target. Capture Derived from the 'breached_at' timestamp within the ticket's SLA metric data. Event type calculated
	Status Changed to Pending	Indicates the process is paused while waiting for a response from the requester. This event is inferred from the ticket 'status' field changing to 'pending'.
Why it matters This activity is crucial for calculating User Confirmation Wait Time. Long durations in this state can significantly inflate the overall resolution time and highlight communication delays. Where to get Inferred from the ticket audit log by identifying a 'Change' event where the 'status' field's new value is 'pending'. Capture Inferred from a status field change to 'pending'. Event type inferred
	Ticket Assigned to Group	Represents the initial routing or triage of an incident to a specific support group. This is typically the first step in assigning responsibility and is recorded as an explicit change event in the ticket's audit history.
Why it matters Tracking group assignments helps analyze the efficiency of the initial triage process and identify delays before a ticket is routed to the correct team. Where to get Captured from the ticket audit log whenever the 'group_id' field is set or changed. The first instance of this change after creation is the initial assignment. Capture Identified by a 'Change' event for the 'group_id' field in the ticket audit log. Event type explicit
	User Satisfaction Rated	Represents the point at which the end-user provides a satisfaction rating for the support they received. This is an explicit event captured in Zendesk after a ticket is solved.
Why it matters Analyzing satisfaction ratings provides crucial feedback on agent performance and process effectiveness, linking process metrics to customer outcomes. Where to get Captured from the satisfaction ratings data associated with the ticket. This typically includes a score ('good' or 'bad') and an optional comment. Capture Event logged when a satisfaction rating is submitted for the ticket. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from Zendesk Support

Steps

Access Zendesk Explore: Log in to your Zendesk Support instance with a user account that has permissions to create and manage reports in Zendesk Explore.
Create a New Report: Navigate to the Explore module. Click the 'Reports' icon in the left-hand navigation bar, then click the 'New report' button.
Select the Dataset: In the 'Choose a dataset' window, select the Support: Ticket updates [default] dataset. This dataset contains the audit trail for every ticket change, which is essential for creating an event log.
Add Initial Attributes (Columns): In the report builder, go to the 'Rows' section. Click 'Add' and select the following attributes. These will form the columns of your event log: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Create Calculated Attributes: This is the most critical step. Go to the 'Calculations' menu (the beaker icon) and select 'Standard calculated attribute'. Create the three attributes defined in the 'Query' section below: ActivityName, SourceSystem, and LastDataUpdate. You will need to copy the provided formulas exactly.
Refine Report Columns: Add your newly created calculated attributes (ActivityName, SourceSystem, LastDataUpdate) to the 'Rows' section. You can now remove the raw fields used to create ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) to clean up the view.
Add Report Filters: Go to the 'Filters' section and click 'Add'. Add a filter for Update - Date and select an appropriate date range (e.g., the last 3 months). Add another filter on your calculated attribute ActivityName and exclude null values to remove any ticket updates that do not correspond to a desired activity.
Run and Review the Report: Zendesk Explore will automatically update the report as you add attributes and filters. Review the data table to ensure the rows and columns appear as expected. The report should show one row per event.
Export the Data to CSV: Once the report is finalized, click the 'Export' button in the top right corner and select 'CSV'. Zendesk will generate and download the CSV file.
Prepare for Upload: Open the exported CSV file. Rename the column headers to match the required attribute names for your process mining tool (e.g., rename 'Ticket ID' to TicketId, 'Update - Timestamp' to EventTimestamp). Ensure the date format for timestamps is ISO 8601 compliant. The file is now ready for upload.

Configuration

Zendesk Dataset: The report must be built on the Support: Ticket updates [default] dataset. This is the only standard dataset that provides the detailed audit trail needed to reconstruct the process event by event.
Date Range Filtering: It is crucial to apply a date filter to limit the data volume. Use the Update - Date attribute as your primary filter. A range of 3-6 months of data is typically recommended for an initial analysis.
Activity Filter: After creating the ActivityName calculated attribute, you must filter the report to exclude rows where this value is null. This removes irrelevant ticket changes (e.g., system updates, tag changes) from your event log.
Calculated Attributes: The logic of this extraction relies heavily on a standard calculated attribute to translate raw ticket field changes into human-readable activity names. Precision in the formula is key.
Prerequisites: The user running the report needs at least a 'Viewer' role in Zendesk Explore. To create and save the report, 'Editor' or 'Admin' permissions are required.

a Sample Query config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Steps

Prerequisites: Ensure you have Python 3.6+ installed on your system along with the requests and pandas libraries. You can install them using pip: pip install requests pandas.
Generate Zendesk API Token: Log in to your Zendesk Support instance as an administrator. Navigate to Admin Center > Apps and integrations > APIs > Zendesk APIs. Under the "API Tokens" section, add a new active API token and securely save the generated token string.
Configure the Python Script: Create a new Python file (e.g., extract_zendesk_logs.py) and copy the provided script into it. Update the placeholder variables at the top of the script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, and ZENDESK_API_TOKEN with your specific credentials. Set the START_TIMESTAMP to define the beginning of your desired data extraction period (a Unix epoch timestamp).
Understand API Endpoints: The script primarily uses two Zendesk API endpoints. The incremental/tickets/cursor.json endpoint is used to efficiently pull all tickets updated since the START_TIMESTAMP. For each ticket, the script then calls the tickets/{ticket_id}/audits.json endpoint to get a detailed history of every change and event.
Execute the Script: Run the script from your terminal using the command: python extract_zendesk_logs.py. The script will begin fetching data from the Zendesk API.
Monitor Script Progress: The script will print the number of tickets processed to the console, allowing you to monitor its progress. Depending on the date range and volume of tickets, this may take a significant amount of time.
Data Retrieval and Pagination: The script automatically handles API pagination. It starts with the initial ticket export URL and follows the after_url provided in each API response until all tickets for the period have been retrieved.
Event Transformation: For each ticket, the script iterates through its audit history. It parses each audit event, mapping Zendesk's internal event types (like Create, Change, Comment) to the required business activities (like Incident Created, Status Changed to Open, Public Reply Sent).
Handling SLA Data: The script includes a dedicated function, get_sla_breach_events, to fetch SLA metrics for each solved ticket. This is necessary because SLA breaches are not standard events in the audit log. This function makes an additional API call to get SLA policy application details.
Generate the Event Log: Once all tickets are processed, the script compiles the extracted events into a pandas DataFrame and saves the final event log as a CSV file named zendesk_incident_event_log.csv in the same directory where the script was run.
Prepare for Upload: Review the generated CSV file for correctness. This file is now in the required format to be uploaded directly into ProcessMind for analysis.

Configuration

Zendesk API Credentials: You must provide your Zendesk subdomain, the email address associated with an admin or agent account, and a valid API token. Store these credentials securely and do not hardcode them in version-controlled scripts for production use.
Start Timestamp (START_TIMESTAMP): This integer value determines the starting point for the data extraction. It must be a Unix epoch timestamp. A recommended starting point is 3-6 months in the past to gather a meaningful amount of data without overwhelming the system. You can use an online converter to get the correct timestamp for a specific date.
API Rate Limiting: The script makes numerous API calls. Zendesk enforces rate limits, which vary by plan. While the script is functional for moderate data volumes, for very large instances, you may need to add time.sleep() calls within the loops to avoid hitting the rate limit and receiving a 429 error.
Required Python Libraries: The script depends on the requests library for making API calls and the pandas library for data manipulation and CSV export. Ensure these are installed in your Python environment.
User Permissions: The user account associated with the API token must have sufficient permissions to read ticket data, including audits and ticket metrics.

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 Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Steps

Prerequisites: Ensure you have Python 3.6+ installed on your system along with the requests and pandas libraries. You can install them using pip: pip install requests pandas.
Generate Zendesk API Token: Log in to your Zendesk Support instance as an administrator. Navigate to Admin Center > Apps and integrations > APIs > Zendesk APIs. Under the "API Tokens" section, add a new active API token and securely save the generated token string.
Configure the Python Script: Create a new Python file (e.g., extract_zendesk_logs.py) and copy the provided script into it. Update the placeholder variables at the top of the script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, and ZENDESK_API_TOKEN with your specific credentials. Set the START_TIMESTAMP to define the beginning of your desired data extraction period (a Unix epoch timestamp).
Understand API Endpoints: The script primarily uses two Zendesk API endpoints. The incremental/tickets/cursor.json endpoint is used to efficiently pull all tickets updated since the START_TIMESTAMP. For each ticket, the script then calls the tickets/{ticket_id}/audits.json endpoint to get a detailed history of every change and event.
Execute the Script: Run the script from your terminal using the command: python extract_zendesk_logs.py. The script will begin fetching data from the Zendesk API.
Monitor Script Progress: The script will print the number of tickets processed to the console, allowing you to monitor its progress. Depending on the date range and volume of tickets, this may take a significant amount of time.
Data Retrieval and Pagination: The script automatically handles API pagination. It starts with the initial ticket export URL and follows the after_url provided in each API response until all tickets for the period have been retrieved.
Event Transformation: For each ticket, the script iterates through its audit history. It parses each audit event, mapping Zendesk's internal event types (like Create, Change, Comment) to the required business activities (like Incident Created, Status Changed to Open, Public Reply Sent).
Handling SLA Data: The script includes a dedicated function, get_sla_breach_events, to fetch SLA metrics for each solved ticket. This is necessary because SLA breaches are not standard events in the audit log. This function makes an additional API call to get SLA policy application details.
Generate the Event Log: Once all tickets are processed, the script compiles the extracted events into a pandas DataFrame and saves the final event log as a CSV file named zendesk_incident_event_log.csv in the same directory where the script was run.
Prepare for Upload: Review the generated CSV file for correctness. This file is now in the required format to be uploaded directly into ProcessMind for analysis.

Configuration

Zendesk API Credentials: You must provide your Zendesk subdomain, the email address associated with an admin or agent account, and a valid API token. Store these credentials securely and do not hardcode them in version-controlled scripts for production use.
Start Timestamp (START_TIMESTAMP): This integer value determines the starting point for the data extraction. It must be a Unix epoch timestamp. A recommended starting point is 3-6 months in the past to gather a meaningful amount of data without overwhelming the system. You can use an online converter to get the correct timestamp for a specific date.
API Rate Limiting: The script makes numerous API calls. Zendesk enforces rate limits, which vary by plan. While the script is functional for moderate data volumes, for very large instances, you may need to add time.sleep() calls within the loops to avoid hitting the rate limit and receiving a 429 error.
Required Python Libraries: The script depends on the requests library for making API calls and the pandas library for data manipulation and CSV export. Ensure these are installed in your Python environment.
User Permissions: The user account associated with the API token must have sufficient permissions to read ticket data, including audits and ticket metrics.

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 Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

Steps

Access Zendesk Explore: Log in to your Zendesk Support instance with a user account that has permissions to create and manage reports in Zendesk Explore.
Create a New Report: Navigate to the Explore module. Click the 'Reports' icon in the left-hand navigation bar, then click the 'New report' button.
Select the Dataset: In the 'Choose a dataset' window, select the Support: Ticket updates [default] dataset. This dataset contains the audit trail for every ticket change, which is essential for creating an event log.
Add Initial Attributes (Columns): In the report builder, go to the 'Rows' section. Click 'Add' and select the following attributes. These will form the columns of your event log: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Create Calculated Attributes: This is the most critical step. Go to the 'Calculations' menu (the beaker icon) and select 'Standard calculated attribute'. Create the three attributes defined in the 'Query' section below: ActivityName, SourceSystem, and LastDataUpdate. You will need to copy the provided formulas exactly.
Refine Report Columns: Add your newly created calculated attributes (ActivityName, SourceSystem, LastDataUpdate) to the 'Rows' section. You can now remove the raw fields used to create ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) to clean up the view.
Add Report Filters: Go to the 'Filters' section and click 'Add'. Add a filter for Update - Date and select an appropriate date range (e.g., the last 3 months). Add another filter on your calculated attribute ActivityName and exclude null values to remove any ticket updates that do not correspond to a desired activity.
Run and Review the Report: Zendesk Explore will automatically update the report as you add attributes and filters. Review the data table to ensure the rows and columns appear as expected. The report should show one row per event.
Export the Data to CSV: Once the report is finalized, click the 'Export' button in the top right corner and select 'CSV'. Zendesk will generate and download the CSV file.
Prepare for Upload: Open the exported CSV file. Rename the column headers to match the required attribute names for your process mining tool (e.g., rename 'Ticket ID' to TicketId, 'Update - Timestamp' to EventTimestamp). Ensure the date format for timestamps is ISO 8601 compliant. The file is now ready for upload.

Configuration

Zendesk Dataset: The report must be built on the Support: Ticket updates [default] dataset. This is the only standard dataset that provides the detailed audit trail needed to reconstruct the process event by event.
Date Range Filtering: It is crucial to apply a date filter to limit the data volume. Use the Update - Date attribute as your primary filter. A range of 3-6 months of data is typically recommended for an initial analysis.
Activity Filter: After creating the ActivityName calculated attribute, you must filter the report to exclude rows where this value is null. This removes irrelevant ticket changes (e.g., system updates, tag changes) from your event log.
Calculated Attributes: The logic of this extraction relies heavily on a standard calculated attribute to translate raw ticket field changes into human-readable activity names. Precision in the formula is key.
Prerequisites: The user running the report needs at least a 'Viewer' role in Zendesk Explore. To create and save the report, 'Editor' or 'Admin' permissions are required.

a Sample Query config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Your Incident Management Data Template

Your Incident Management Data Template

Incident Management Attributes

Incident Management Activities

Extraction Guides

Zendesk Explore UI Report to CSV File Export

Steps

Configuration

a Sample Query config

Python Script using the Zendesk Support REST API

Steps

Configuration

a Sample Query python

Zendesk Incremental Export API for Bulk Data Sync

Steps

Configuration

a Sample Query python

Third-Party ETL Tool with Zendesk API Connector

Steps

Configuration

a Sample Query config

Ready to Get Started?

Optimize Incident Management, Resolve Faster Today

Your Incident Management Data Template

Your Incident Management Data Template

Incident Management Attributes

Incident Management Activities

Extraction Guides

Zendesk Explore UI Report to CSV File Export

Steps

Configuration

a Sample Query config

Python Script using the Zendesk Support REST API

Steps

Configuration

a Sample Query python

Zendesk Incremental Export API for Bulk Data Sync

Steps

Configuration

a Sample Query python

Third-Party ETL Tool with Zendesk API Connector

Steps

Configuration

a Sample Query config

We value your privacy

Ready to Get Started?

Optimize Incident Management, Resolve Faster Today