> Continuous Process Improvement > Service Request Management > Zendesk Support > Data Template

Your Service Request Management Data Template

Zendesk Support

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

Your Service Request Management Data Template

This template provides a comprehensive guide for extracting the necessary data to analyze your Service Request Management process in Zendesk Support. It outlines the essential data attributes to collect, key activities to track, and practical guidance on how to extract this information directly from your system. Use this resource to build a robust event log for your process mining initiatives.

Recommended attributes for comprehensive analysis
Key service request activities to track
Extraction guidance for Zendesk Support data

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

Download Template

Service Request Management Attributes

These are the recommended data fields to include in your event log for comprehensive service request management analysis within Zendesk Support.

5 Required 7 Recommended 10 Optional

	Name	Description
	Activity ActivityName	The name of the business activity or event that occurred for a service request.
Description The Activity represents a distinct step or event in the service request lifecycle, such as 'Service Request Created', 'Request Assigned to Agent', or 'Service Request Resolved'. These activities are derived from changes recorded in the Zendesk ticket's audit log, which tracks modifications to fields like status, assignee, priority, and the addition of comments. Analyzing activities is the core of process mining. It allows for the visualization of the process map, identification of bottlenecks between steps, and analysis of rework loops. By understanding the sequence and frequency of activities, organizations can identify inefficiencies and opportunities for process improvement. Why it matters This attribute defines the steps in the process, enabling the visualization of process maps and the analysis of process flow, variations, and conformance. Where to get This is conceptually derived from events logged in the Zendesk Ticket Audits API. For example, a change in the 'status' field from 'new' to 'open' can be mapped to an activity like 'Request Triaged'. Examples Service Request CreatedAgent ReassignedService Request Resolved
	Service Request ID ServiceRequestId	The unique identifier for each service request ticket within Zendesk.
Description The Service Request ID, often called Ticket ID in Zendesk, serves as the primary key for each case. It links all related activities, comments, and status changes together, from the moment a request is created until it is closed. This allows for a complete, end-to-end trace of a single request's lifecycle. In process mining analysis, this attribute is fundamental. It defines the case, enabling the reconstruction of process flows, the identification of variants, and the calculation of case-level metrics like cycle time. Every event in the dataset must be associated with a Service Request ID to understand its context within the overall process. Why it matters This is the essential case identifier that connects all events in a service request's journey, making it possible to analyze the end-to-end process. Where to get Zendesk Tickets API, field 'id'. Examples 102451024610247
	Start Time EventTimestamp	The precise date and time when the activity occurred.
Description Event Timestamp, or Start Time, records the exact moment an activity took place. For instance, it captures when an agent was assigned, when a public reply was sent, or when the ticket status was changed to 'Resolved'. This temporal data is sourced from the audit log of each Zendesk ticket. This attribute is critical for any time-based analysis. It is used to order events chronologically, calculate the duration between activities, measure waiting times, and analyze the overall case cycle time. It is fundamental for identifying bottlenecks and evaluating performance against time-based targets like SLAs. Why it matters This timestamp orders events chronologically and is essential for all duration, performance, and bottleneck analysis. Where to get Zendesk Ticket Audits API, field 'created_at' for each audit event. Examples 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Last Data Update LastDataUpdate	The timestamp indicating the last time the data was refreshed from the source system.
Description This attribute records the date and time of the most recent data extraction from Zendesk Support. It provides context on the freshness of the data being analyzed, ensuring that users are aware of how current the process view is. For ongoing monitoring and dashboarding, this information is vital. It allows analysts and business users to understand if they are looking at near real-time data or a snapshot from a previous period, which affects the validity of their conclusions. Why it matters Provides crucial context on data freshness, letting users know how up-to-date the analysis is. Where to get This is a metadata field generated and stamped on the dataset at the time of data extraction. Examples 2023-10-27T08:00:00Z
	Source System SourceSystem	Indicates the system from which the data was extracted.
Description This attribute specifies the origin of the service request data. For this process view, the value will consistently be 'Zendesk Support', identifying it as the system of record for all service management activities. In environments with multiple integrated systems, this field is crucial for data lineage and troubleshooting. It ensures that analyses are correctly scoped to the intended system and helps differentiate data when merged from various sources. Why it matters Identifies the data's system of origin, ensuring data lineage and preventing confusion when data from multiple systems is combined. Where to get This is a static value ('Zendesk Support') added during data extraction and transformation. Examples Zendesk Support
	Agent Name AgentName	The name of the agent assigned to the service request at the time of the event.
Description This attribute identifies the support agent responsible for handling the service request. The assigned agent can change multiple times throughout the ticket's lifecycle, and this field captures who was responsible at each step. Agent Name is critical for performance analysis. It allows for filtering and segmenting data to assess workload distribution, resolution times per agent, and the frequency of reassignments. This helps in building the Agent & Team Performance dashboard and understanding individual contributions to the overall process efficiency. Why it matters This attribute is vital for analyzing agent performance, workload distribution, and the impact of reassignments on resolution times. Where to get Zendesk Users API, by joining the 'assignee_id' from the Tickets API response. Examples Jane DoeJohn SmithEmily Jones
	Assigned Team AssignedTeam	The support team or group assigned to the service request.
Description This attribute indicates which team or group within the support organization is responsible for the service request. In Zendesk, these are known as 'Groups'. Tickets are often assigned to a group first before being picked up by an individual agent. Analyzing by Assigned Team is essential for understanding team-level performance and workload. It helps answer questions about which teams handle which types of requests, their average resolution times, and their SLA adherence rates. This is a primary dimension for the Agent & Team Performance dashboard. Why it matters Enables analysis of team performance, workload balancing, and routing efficiency between different support groups. Where to get Zendesk Groups API, by joining the 'group_id' from the Tickets API response. Examples Tier 1 SupportTechnical SupportBilling
	Request Channel RequestChannel	The channel through which the service request was submitted (e.g., Email, Web Form, Phone).
Description This attribute identifies the submission source of the service request. Zendesk captures how a ticket was created, whether through email, a web portal, an API integration, chat, or other channels. This provides context on the customer's interaction method. The Request Channel is a powerful dimension for analysis. It supports the 'Request Channel Efficiency' dashboard by allowing comparisons of resolution times, satisfaction ratings, and rework rates across different channels. This can help businesses optimize their support channels and guide users to the most efficient ones. Why it matters Helps analyze the efficiency and outcomes of different customer support channels, enabling targeted improvements. Where to get Zendesk Tickets API, object 'via' and its 'channel' property. Examples webemailapichat
	Request Priority RequestPriority	The priority level assigned to the service request, such as Low, Normal, High, or Urgent.
Description Request Priority is a classification that indicates the urgency of a service request. This level often dictates the target resolution times and SLA policies applied to the ticket. The priority can be set initially by the system or user and may be changed by an agent during the ticket's lifecycle. This attribute is crucial for segmentation and root cause analysis. It helps in analyzing whether high-priority tickets are resolved faster than low-priority ones and is a key factor in the 'Service Request Escalation Trends' and 'SLA Adherence' dashboards. Why it matters Allows for segmenting requests by urgency, which is critical for analyzing SLA compliance and ensuring that critical issues are handled promptly. Where to get Zendesk Tickets API, field 'priority'. Examples LowNormalHighUrgent
	Request Status RequestStatus	The status of the service request at the time of the event (e.g., New, Open, Pending).
Description Request Status represents the state of the ticket at a specific point in time. Zendesk has several standard statuses like New, Open, Pending, On-hold, Solved, and Closed, which mark the progress of a request through its lifecycle. Changes in this field are primary triggers for creating activities in the event log. Analyzing the time spent in different statuses is a core part of bottleneck analysis. It helps identify where tickets are getting stuck, for example, spending too much time in a 'Pending' or 'On-hold' state. Understanding status transitions is also key to discovering rework loops. Why it matters Tracking the status is fundamental to understanding the request's progress and identifying how much time is spent in waiting or active states. Where to get Zendesk Tickets API, field 'status'. Examples NewOpenPendingSolvedClosed
	Service Type ServiceType	The category or type of the service request (e.g., Incident, Question, Problem, Task).
Description Service Type categorizes the nature of the service request. Zendesk uses a 'type' field to distinguish between different kinds of support interactions. This initial classification helps in routing the ticket to the correct team and applying the appropriate processes. This attribute is essential for filtering and comparison. It allows analysts to examine the process flows for different types of requests, which often have very different resolution paths and SLAs. It is a key dimension for the Agent & Team Performance dashboard to see who is best at handling specific request types. Why it matters Categorizes requests to allow for separate analysis of different processes, such as incidents versus questions, which follow unique paths. Where to get Zendesk Tickets API, field 'type'. Examples questionincidentproblemtask
	Ticket Tags TicketTags	A list of tags applied to the service request for categorization and routing.
Description Tags are flexible labels that can be added to tickets manually by agents or automatically through business rules. They are used to add specific context or categories to a ticket that may not be covered by standard fields like Type or Priority. Tags are an extremely versatile attribute for process mining analysis. They can be used to filter for very specific scenarios, track custom workflows, or identify root causes. For example, a 'VIP' tag could be used to analyze the process for key customers, or a 'product_bug' tag could be used to trace the lifecycle of defect reports. Why it matters Offers a flexible way to slice and dice the data, allowing for deep-dive analysis into specific sub-processes or ticket attributes not captured in other fields. Where to get Zendesk Tickets API, field 'tags'. This is an array of strings. Examples sales_inquirybilling_issuefeature_requestvip_customer
	Agent Reassignment Count AgentReassignmentCount	The total number of times a request was reassigned from one agent to another.
Description This attribute is a counter that increments each time the 'assignee_id' field on a ticket changes. A high number of reassignments for a single ticket can indicate a variety of process issues, such as incorrect initial routing, lack of agent knowledge, or requests that are too complex for a single agent to handle. This is a key metric for measuring process efficiency and directly supports the 'Agent Reassignment Rate' KPI. Analyzing cases with high reassignment counts can reveal opportunities to improve routing rules, agent training, or knowledge base resources to ensure tickets get to the right person faster. Why it matters Helps quantify internal handoffs and identifies process friction, as high reassignment rates often lead to delays and inefficiency. Where to get Calculated by counting the number of 'assignee_id' changes in the Zendesk Ticket Audits API for each ticket. Examples 013
	End Time EndTime	The precise date and time when the activity was completed.
Description The End Time marks the completion of an activity. For many events in Zendesk, the duration is instantaneous, so the End Time is the same as the Start Time. However, for state-based activities like 'Request Placed On-Hold', the End Time would be when the ticket is taken off hold. This attribute is essential for calculating the duration of specific activities, which is key to bottleneck analysis. By comparing the Start Time and End Time of an activity, one can measure its processing time directly, helping to pinpoint which steps consume the most time. Why it matters Enables the calculation of individual activity durations, which is critical for identifying process bottlenecks and measuring step-level efficiency. Where to get This is often the same as the StartTime for discrete events. For status durations, it's the timestamp of the next event that changes the status. Examples 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Is First Contact Resolution IsFirstContactResolution	A flag indicating if the request was resolved by the first assigned agent without reassignments or replies from the requestor.
Description First Contact Resolution (FCR) is a crucial metric indicating that a customer's issue was resolved in a single interaction. This calculated attribute is a boolean flag that is true if a ticket was solved by the first agent it was assigned to, without any reassignments and with only one agent reply. This attribute directly supports the 'First Contact Resolution Rate' KPI. Analyzing the characteristics of FCR cases can provide a blueprint for process excellence. Conversely, analyzing cases that fail FCR can highlight opportunities for better agent training, improved knowledge base articles, or more effective initial triage. Why it matters Measures the ability to resolve issues efficiently in a single touch, which is a strong driver of both customer satisfaction and operational efficiency. Where to get This is a complex calculated attribute. It requires analyzing the event log for a ticket to check for agent reassignments and the number of public replies from agents. Examples truefalse
	Is Rework IsRework	A flag that is true if the service request was reopened after being solved.
Description This boolean flag identifies cases that have undergone rework. A service request is typically considered rework if its status changes from 'Solved' back to an open state, indicating that the initial resolution was not sufficient and the customer had to follow up on the same issue. This attribute is essential for calculating the 'Service Request Rework Rate' KPI and for the 'Rework and Reopening Activity Analysis' dashboard. By flagging rework cases, analysts can isolate these inefficient process flows, discover the root causes of reopenings, and work to improve first contact resolution. Why it matters Identifies process failures where resolution was not final, highlighting issues with quality and efficiency that directly impact customer satisfaction. Where to get Calculated by analyzing the sequence of statuses for a ticket in the Zendesk Ticket Audits API. A transition from 'solved' to 'open' indicates rework. Examples truefalse
	Is SLA Breached IsSlaBreached	A flag indicating whether the service request breached any of its SLA targets.
Description This attribute is a boolean or categorical flag that shows the SLA outcome for a ticket. It can indicate states like 'Met', 'Breached', or 'Active'. This is determined by comparing the actual response or resolution times against the targets defined in the applied SLA policy. This is a critical attribute for the 'SLA Adherence and Breach Analysis' dashboard. It allows for easy counting and visualization of compliant versus non-compliant tickets. Further analysis can then focus on the process characteristics of breached tickets to identify root causes, such as long waiting times or excessive reassignments. Why it matters Directly measures performance against service level commitments, a key indicator of service quality and customer satisfaction. Where to get Derived from the Zendesk Ticket Metrics API, which provides information on SLA status for each ticket. Examples MetBreachedActive
	Requestor Name RequestorName	The name of the end-user or customer who submitted the service request.
Description This attribute identifies the individual who initiated the service request. Linking the request to a specific customer provides a user-centric view of the support process. In process analysis, the requestor can be used to analyze patterns for specific customers or customer segments. For example, one might investigate if certain customers experience longer resolution times or have higher rates of rework, which could indicate issues with a product or service they are using. Why it matters Connects the process to the customer, enabling analysis of customer-specific issues, repeat requests, and satisfaction levels. Where to get Zendesk Users API, by joining the 'requester_id' from the Tickets API response. Examples Alice JohnsonBob WilliamsCharlie Brown
	Requestor Organization RequestorOrganization	The organization or company to which the requestor belongs.
Description This attribute links the service request to a specific customer organization. This is particularly relevant in B2B support scenarios, where service level agreements and support contracts are often defined at the organization level. Analyzing data by organization allows for a company-level view of support performance. It can help identify organizations that are creating a high volume of tickets, experiencing recurring issues, or have low satisfaction scores. This is valuable for account management and identifying broader customer health trends. Why it matters Enables B2B service analysis by grouping requests by company, which is crucial for managing customer relationships and SLAs at an organizational level. Where to get Zendesk Organizations API, by joining the 'organization_id' from the Tickets API response. Examples Acme CorporationGlobal Tech Inc.Innovate Solutions
	Satisfaction Rating SatisfactionRating	The satisfaction score provided by the requestor after the ticket was solved.
Description This attribute captures the customer's feedback on their support experience, typically collected via a survey after a ticket is marked as solved. Common ratings include 'Good' or 'Bad', sometimes with a comment. Satisfaction Rating is a critical outcome metric. Correlating process patterns with satisfaction scores can reveal what process behaviors lead to happy or unhappy customers. For example, analysis might show that high reassignment rates or long resolution times are strongly correlated with negative satisfaction ratings. Why it matters Provides a direct link between process execution and customer outcomes, helping to identify which process behaviors drive customer satisfaction. Where to get Zendesk Tickets API, field 'satisfaction_rating.score' or 'satisfaction_rating.reason'. Examples GoodBadOffered
	Service Request Cycle Time ServiceRequestCycleTime	The total duration from the creation of a service request to its final resolution.
Description This calculated metric measures the end-to-end processing time for a service request. It is typically calculated as the time difference between the 'Service Request Resolved' activity and the 'Service Request Created' activity. This is one of the most important high-level KPIs for any support process. This attribute directly supports the 'Average Service Request Cycle Time' KPI and the 'End-to-End Cycle Time' dashboard. Analyzing this metric across different dimensions, such as request type or priority, helps identify which factors have the biggest impact on overall efficiency. Why it matters This is a primary KPI for measuring overall process efficiency and customer experience, indicating how long it takes to deliver a resolution. Where to get Calculated as the difference between the first and last (resolution) event timestamps for a case. Examples 259200s (3 days)86400s (1 day)3600s (1 hour)
	SLA Policy Name SlaPolicyName	The name of the Service Level Agreement (SLA) policy applied to the request.
Description This attribute identifies the specific SLA policy that governs the target response and resolution times for the service request. A policy is typically determined by factors like the request's priority, type, or the customer's subscription level. Knowing the applied SLA policy is essential for the 'SLA Adherence and Breach Analysis' dashboard. It provides the necessary context to evaluate performance, as different policies will have different targets. This allows for a fair and accurate assessment of whether a ticket met its specific service level objectives. Why it matters Provides the context for SLA analysis by identifying which set of targets a request was measured against, enabling accurate compliance reporting. Where to get Zendesk Ticket Metrics API. SLA data is often associated with the ticket's metrics. Examples Urgent - 1 Hour ResponseStandard - 24 Hour ResolutionPremium Customer SLA

Required Recommended Optional

Service Request Management Activities

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

7 Recommended 6 Optional

	Activity	Description
	Public Reply Sent	This activity marks any communication sent from an agent to the requester. This is captured as an explicit 'Comment' event in the Zendesk ticket data where the 'public' attribute is true.
Why it matters These events are crucial for analyzing communication frequency, measuring agent response times, and identifying the number of interactions required for resolution. Where to get This is an explicit 'Comment' event in the ticket data. The event details include a 'public: true' attribute, distinguishing it from internal notes. Capture Captured from ticket 'Comment' events where the 'public' flag is set to true. Event type explicit
	Request Assigned to Agent	This activity occurs when a service request is assigned to a specific agent for the first time. It is inferred from a 'Change' event in the ticket audit log where the 'assignee_id' field is populated from null or a group ID.
Why it matters This marks the start of active work by an agent and is critical for measuring initial response times, first assignment lag, and agent workload distribution. Where to get Inferred from the first 'Change' event on the 'assignee_id' field in the ticket audit log where a specific user ID is set. Capture Inferred from the first change event that sets the 'assignee_id' field to an agent. Event type inferred
	Service Request Closed	Represents the final, permanent closure of the service request. A ticket moves to the 'closed' state automatically after a set period of being 'solved' and can no longer be reopened.
Why it matters This activity marks the definitive end of the service request process. It provides the final endpoint for calculating the complete case duration. Where to get Inferred from a 'Change' event on the 'status' field in the ticket audit log, where the new value is 'closed'. Capture Inferred from a 'Change' event in the audit log where status becomes 'closed'. Event type inferred
	Service Request Created	Marks the beginning of the service request lifecycle when a new ticket is submitted by a requester through any channel. This is captured as a 'Create' event in the Zendesk ticket audit log, providing a definitive start time for the process.
Why it matters This activity serves as the primary start event for every service request, making it essential for calculating end-to-end cycle times and analyzing request intake volumes. Where to get This is recorded as a 'Create' event type in the Zendesk ticket audit log. The timestamp of this event is the creation time of the service request ticket. Capture Captured directly from the 'Create' event in the ticket audit log. Event type explicit
	Service Request Reopened	Occurs when a requester replies to a request that is in a 'solved' state, automatically changing its status back to 'open'. This signifies that the proposed resolution was not sufficient.
Why it matters This activity is the primary indicator of rework. Analyzing its frequency helps measure resolution quality and identify causes of customer dissatisfaction. Where to get Inferred from a 'Change' event on the 'status' field in the ticket audit log, where the previous value was 'solved' and the new value is 'open'. Capture Inferred from a status change from 'solved' to 'open'. Event type inferred
	Service Request Resolved	This activity marks the point where an agent has provided a solution and changed the ticket status to 'solved'. The request is considered complete from the agent's perspective but can still be reopened by the requester.
Why it matters This is a major milestone that signifies the end of active agent work. The time to reach this state is a primary measure of resolution efficiency. Where to get Inferred from a 'Change' event on the 'status' field in the ticket audit log, where the new value is 'solved'. Capture Inferred from a 'Change' event in the audit log where status becomes 'solved'. Event type inferred
	SLA Target Breached	This activity marks the point in time when a service request fails to meet a defined SLA target, such as first reply time or resolution time. Zendesk logs this as an explicit event when a target is missed.
Why it matters This is a critical event for compliance monitoring and is a key input for the SLA Adherence Rate KPI. It pinpoints failures to meet service commitments. Where to get Captured from the 'SLABreach' event within the Zendesk ticket events or audit log. The event specifies which SLA metric was breached. Capture Identified through the explicit 'SLABreach' event in ticket data. Event type explicit
	Agent Reassigned	Represents the transfer of ownership of a service request from one agent to another. This is inferred from any subsequent 'Change' event on the 'assignee_id' field after the initial assignment.
Why it matters Tracking reassignments is key to calculating the Agent Reassignment Rate KPI, which helps identify process inefficiencies, incorrect routing, or knowledge gaps. Where to get Inferred from 'Change' events on the 'assignee_id' field in the ticket audit log, excluding the very first assignment event for the ticket. Capture Inferred from the second and subsequent 'Change' events on the 'assignee_id' field. Event type inferred
	Internal Note Added	An internal note or comment has been added to the service request by an agent, visible only to other agents. This is recorded as a 'Comment' event where the 'public' attribute is false.
Why it matters Tracking internal notes provides insight into collaboration between agents or teams, which can be a source of delay or a key to efficient problem-solving. Where to get This is an explicit 'Comment' event in the ticket data. The event details include a 'public: false' attribute, indicating it is an internal note. Capture Captured from ticket 'Comment' events where the 'public' flag is set to false. Event type explicit
	Priority Changed	Indicates that the priority level of the service request, such as 'Low', 'Normal', 'High', or 'Urgent', has been updated. This is captured as a 'Change' event on the 'priority' field in the ticket audit log.
Why it matters Analyzing priority changes helps identify requests that increase in urgency over time and assesses whether prioritization is being managed effectively. Where to get Recorded as a 'Change' event on the 'priority' field within the Zendesk ticket audit log, showing the previous and new values. Capture Inferred from 'Change' events on the 'priority' field in the audit log. Event type inferred
	Request Escalated	Represents the formal escalation of a service request to a higher support tier, a different team, or management. This is typically inferred from a change in the ticket's assigned group or a change in a custom field designated for tracking escalations.
Why it matters Monitoring escalations helps identify complex requests, training needs for front-line agents, and systemic issues that require higher-level intervention. Where to get This is not a standard event. It must be inferred from a 'Change' event on the 'group_id' field to an escalation group or from a change to a custom ticket field used for escalation tracking. Capture Inferred from a change of 'group_id' or a custom 'escalation' field. Event type inferred
	Request Placed On-Hold	This activity occurs when the service request's status is changed to 'on-hold', typically indicating that the agent is awaiting information from the requester or a third party. This is inferred from a status change event.
Why it matters This helps isolate and measure waiting times that are outside of the support team's direct control, providing a more accurate view of agent handling time. Where to get Inferred from a 'Change' event on the 'status' field in the ticket audit log, where the new value is 'on-hold'. Capture Inferred from a 'Change' event in the audit log where status becomes 'on-hold'. Event type inferred
	SLA Target Applied	Represents the moment a Service Level Agreement (SLA) policy is applied to the service request ticket. This event is logged explicitly when the ticket's properties match the conditions of an active SLA policy.
Why it matters Tracking when an SLA is applied is crucial for monitoring compliance, analyzing potential breaches, and understanding the expected service timeline for different request types. Where to get Captured from the 'SLAPolicyApplied' event within the Zendesk ticket events or audit log. This event specifies which policy was matched. Capture Identified through the explicit 'SLAPolicyApplied' event in ticket data. Event type explicit

Recommended Optional

Extraction Guides

How to get your data from Zendesk Support

Steps

Access Zendesk Explore and Create the Primary Report: Navigate to the Zendesk products icon in the top right bar and select Explore. Once in Explore, click the Queries icon on the left, and then click New query. Select the Support: Ticket updates dataset as the source.
Configure Metrics and Attributes for Ticket Events: In the query builder, add a metric like COUNT(Tickets) to visualize data. Then, go to the Rows section and add the following attributes: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type, and Ticket tags.
Create a Calculated Attribute for ActivityName: To translate raw updates into meaningful activities, create a standard calculated attribute. Go to the Calculations menu (calculator icon), select Standard calculated attribute, and name it ActivityName. Paste the logic provided in the Query section into the formula box. This formula maps different ticket update events to the required activity names.
Refine and Filter the Primary Report: Add the new ActivityName attribute to the Rows section. Create a filter on this attribute to exclude any (null) or unwanted system-generated values to clean the dataset. Also, add a filter for Ticket created - Date to limit the query to a manageable time frame, such as the last 6 months.
Create the Second Report for SLA Events: Create another new query, this time selecting the Support: SLAs dataset. This is necessary because SLA events are not available in the Ticket updates dataset.
Configure the SLA Report: In the SLA query, add COUNT(SLA tickets) to Metrics. In the Rows section, add Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status, and Updater name. We will infer the activity from the SLA status in the transformation step.
Export Both Datasets: Run both queries in the Explore UI. Once the tables are generated, click the Export button and choose CSV as the format. You will now have two separate CSV files.
Merge and Transform the Data: Combine the two CSV files using a spreadsheet tool like Microsoft Excel or a scripting language like Python. The goal is to create a single event log. For the SLA file, you will need to create the ActivityName column. If SLA status is Active, the activity is SLA Target Applied. If SLA status is Breached, the activity is SLA Target Breached. Use the SLA updated - Timestamp as the EventTimestamp.
Standardize Column Headers: In the final merged file, rename the columns to match the required format for process mining. For example, rename Ticket ID to ServiceRequestId, Update - Timestamp to EventTimestamp, and Updater name to AgentName.
Add Static Columns and Finalize: Add two new columns to your final CSV file. Populate SourceSystem with the value 'Zendesk'. Populate LastDataUpdate with the timestamp of when you performed the export. The file is now ready for upload.

Configuration

Zendesk Plan: A Zendesk Support plan that includes Zendesk Explore Professional or Enterprise is required to create custom queries and attributes.
Permissions: You need to be an Agent with permissions to create and edit queries in Explore. Typically, this is an Administrator or an agent with a custom role.
Dataset Selection: This method requires creating two separate reports based on two different datasets, Support: Ticket updates for general events and Support: SLAs for SLA specific events.
Date Range Filter: It is critical to apply a date range filter, for example on Ticket created - Date, to keep the data volume manageable. A range of 3 to 6 months is recommended for initial analysis.
Calculated Attributes: The logic for deriving activity names is handled by a complex custom calculated attribute within Explore. Ensure the formula is created correctly to avoid errors in the output.
Data Volume: The Zendesk Explore UI and export functionality can be slow or may time out with very large datasets. For extractions covering more than a year of data or millions of tickets, consider breaking the export into smaller, batched time periods.

a Sample Query config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Steps

Prerequisites: Ensure you have Python 3.6 or newer installed on your system. You will also need administrative access to your Zendesk Support instance to generate an API token.
Install Python Libraries: Open your terminal or command prompt and install the necessary Python libraries using pip. The requests library is used for making API calls, and pandas is used for data manipulation and exporting to a CSV file.
```
pip install requests pandas
```
Generate Zendesk API Token: Log in to Zendesk as an administrator. Navigate to Admin Center > Apps and integrations > APIs > Zendesk API. Under the Token Access section, enable it if it is not already, and click "Add API token". Provide a description, for example "ProcessMind Extraction", and copy the generated token. This token will not be shown again.
Configure the Python Script: Open the provided Python script in a text editor. Fill in the configuration variables at the top of the file: ZENDESK_SUBDOMAIN (your company's Zendesk domain name), ZENDESK_EMAIL (the email address of the admin user associated with the token), and ZENDESK_API_TOKEN. Also, set the START_TIME_STR to define the beginning of the data extraction period, typically 3 to 6 months ago.
Understand the Script's Logic: The script first fetches a list of tickets updated within the specified date range using the efficient Incremental Tickets API. For each ticket, it then fetches its complete audit trail, comments, and SLA metrics. It processes these events chronologically to build a detailed history.
Map Zendesk Events to Activities: The script contains logic to translate raw Zendesk events into the required business activities. For example, a 'Change' event on the 'status' field is mapped to activities like 'Service Request Resolved' or 'Request Placed On-Hold'. Comment events are checked to determine if they are a 'Public Reply Sent' or an 'Internal Note Added'.
Run the Extraction Script: Execute the script from your terminal by running python your_script_name.py. The script will print progress updates as it fetches data from the Zendesk API. Depending on the data volume and API rate limits, this process may take some time.
Review the Output File: Once the script completes, it will generate a CSV file named zendesk_event_log.csv in the same directory. This file contains the extracted event log with all specified activities and attributes.
Prepare for Upload: Open the CSV file to ensure it is correctly formatted. The column headers should match the required attributes: ServiceRequestId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, and others. This file is now ready for upload to ProcessMind.

Configuration

Zendesk API Access: The script requires an active API token associated with an administrator or an agent with sufficient permissions. The user email for the script configuration must be the same one that created the API token.
Script Parameters: Before running, you must configure these key variables within the script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME_STR. The START_TIME_STR should be in 'YYYY-MM-DD' format.
Date Range: We recommend starting with an extraction period of the last 3 to 6 months of data (START_TIME_STR). This provides a representative dataset for analysis without causing excessive runtime or hitting API limits too frequently. A larger date range will significantly increase the extraction time.
Incremental Exports API: The script uses the Incremental Exports endpoint (/api/v2/incremental/tickets/cursor.json) to efficiently fetch only tickets that have been updated since the last run or a specified start time. This is much more performant than scanning all tickets.
Rate Limiting: Zendesk enforces API rate limits. The script includes basic handling to pause if a rate limit is hit, but for extremely large instances, the extraction may take a considerable amount of time. It is best to run the script during off-peak hours.
Escalation Logic: The activity 'Request Escalated' is inferred from a change in the group_id field. If your organization uses a different mechanism, such as a custom ticket field, you will need to modify the script's logic to correctly identify escalations.

a Sample Query python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

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

class=class="hl-string">"hl-comment"># Set up constants and session
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.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

class=class="hl-string">"hl-comment"># Caches for user and group names to reduce API calls
user_cache = {}
group_cache = {}

def get_user_name(user_id):
    if not user_id:
        return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'User ID {user_id}'

def get_group_name(group_id):
    if not group_id:
        return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'Group ID {group_id}'

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'A critical error occurred: {e}')
            break

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

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

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

Steps

Access Zendesk Explore and Create the Primary Report: Navigate to the Zendesk products icon in the top right bar and select Explore. Once in Explore, click the Queries icon on the left, and then click New query. Select the Support: Ticket updates dataset as the source.
Configure Metrics and Attributes for Ticket Events: In the query builder, add a metric like COUNT(Tickets) to visualize data. Then, go to the Rows section and add the following attributes: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type, and Ticket tags.
Create a Calculated Attribute for ActivityName: To translate raw updates into meaningful activities, create a standard calculated attribute. Go to the Calculations menu (calculator icon), select Standard calculated attribute, and name it ActivityName. Paste the logic provided in the Query section into the formula box. This formula maps different ticket update events to the required activity names.
Refine and Filter the Primary Report: Add the new ActivityName attribute to the Rows section. Create a filter on this attribute to exclude any (null) or unwanted system-generated values to clean the dataset. Also, add a filter for Ticket created - Date to limit the query to a manageable time frame, such as the last 6 months.
Create the Second Report for SLA Events: Create another new query, this time selecting the Support: SLAs dataset. This is necessary because SLA events are not available in the Ticket updates dataset.
Configure the SLA Report: In the SLA query, add COUNT(SLA tickets) to Metrics. In the Rows section, add Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status, and Updater name. We will infer the activity from the SLA status in the transformation step.
Export Both Datasets: Run both queries in the Explore UI. Once the tables are generated, click the Export button and choose CSV as the format. You will now have two separate CSV files.
Merge and Transform the Data: Combine the two CSV files using a spreadsheet tool like Microsoft Excel or a scripting language like Python. The goal is to create a single event log. For the SLA file, you will need to create the ActivityName column. If SLA status is Active, the activity is SLA Target Applied. If SLA status is Breached, the activity is SLA Target Breached. Use the SLA updated - Timestamp as the EventTimestamp.
Standardize Column Headers: In the final merged file, rename the columns to match the required format for process mining. For example, rename Ticket ID to ServiceRequestId, Update - Timestamp to EventTimestamp, and Updater name to AgentName.
Add Static Columns and Finalize: Add two new columns to your final CSV file. Populate SourceSystem with the value 'Zendesk'. Populate LastDataUpdate with the timestamp of when you performed the export. The file is now ready for upload.

Configuration

Zendesk Plan: A Zendesk Support plan that includes Zendesk Explore Professional or Enterprise is required to create custom queries and attributes.
Permissions: You need to be an Agent with permissions to create and edit queries in Explore. Typically, this is an Administrator or an agent with a custom role.
Dataset Selection: This method requires creating two separate reports based on two different datasets, Support: Ticket updates for general events and Support: SLAs for SLA specific events.
Date Range Filter: It is critical to apply a date range filter, for example on Ticket created - Date, to keep the data volume manageable. A range of 3 to 6 months is recommended for initial analysis.
Calculated Attributes: The logic for deriving activity names is handled by a complex custom calculated attribute within Explore. Ensure the formula is created correctly to avoid errors in the output.
Data Volume: The Zendesk Explore UI and export functionality can be slow or may time out with very large datasets. For extractions covering more than a year of data or millions of tickets, consider breaking the export into smaller, batched time periods.

a Sample Query config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Zendesk Explore UI for Report and Data Export

Steps

Configuration

a Sample Query config

Zendesk REST API Extraction via Python Script

Steps

Configuration

a Sample Query python

Zendesk Support Native Full Account JSON Export

Steps

Configuration

a Sample Query config

Ready to Get Started?

Optimize Service Request Management. Reduce Delays Now.

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Zendesk Explore UI for Report and Data Export

Steps

Configuration

a Sample Query config

Zendesk REST API Extraction via Python Script

Steps

Configuration

a Sample Query python

Zendesk Support Native Full Account JSON Export

Steps

Configuration

a Sample Query config

We value your privacy

Ready to Get Started?

Optimize Service Request Management. Reduce Delays Now.