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

Your Problem Management Data Template

Zendesk Support

Problem Management Attributes (20) Problem Management Activities (12) Extraction Guides (3)

Your Problem Management Data Template

This template provides a comprehensive framework for mapping your problem management lifecycle within Zendesk Support. It outlines the essential attributes, process milestones, and extraction logic needed to identify bottlenecks in root cause analysis. By following this structure, you can build a high-quality event log for deeper process insights.

Recommended attributes for detailed analysis
Key process activities and status transitions
Extraction guidance for Zendesk Support data

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

Download Template

Problem Management Attributes

These recommended data fields provide the necessary context to analyze ticket categories, priority levels, and ownership throughout the entire problem resolution lifecycle.

5 Required 8 Recommended 7 Optional

	Name	Description
	Activity ActivityName	The name of the event or action performed on the problem record.
Description This attribute captures the specific step or action taken during the lifecycle of the problem record. Examples include status changes like 'Open' to 'Pending', assignment changes, or specific workflow steps like 'Workaround Published'. In analysis, this forms the nodes of the process map. The sequence of these activities allows analysts to visualize the flow of work, identify bottlenecks, and measure the time taken between specific process steps. Why it matters It defines the 'what' of the process, enabling the visualization of the process flow and variant analysis. Where to get Derived from Zendesk Ticket Audits or Ticket Metrics Examples Problem Record LoggedInvestigation CommencedWorkaround Published
	Last Data Update LastDataUpdate	The timestamp indicating when the problem record was last modified.
Description This attribute reflects the most recent time the problem record data was updated in the source system. It is distinct from the event timestamp, as it refers to the record level rather than the activity level. In analysis, this helps determine the freshness of the data. It is used to identify if the dataset is current or if there are synchronization lags between the source system and the process mining environment. Why it matters It tracks data freshness and assists in incremental data loading strategies. Where to get Zendesk Ticket object, field 'updated_at' Examples 2023-11-01T14:20:00Z
	Problem Record ProblemRecordId	The unique numeric identifier assigned to the problem ticket in Zendesk.
Description This attribute represents the unique key for the problem record within the Zendesk Support system. It serves as the central Case ID for process mining, allowing all subsequent events, updates, and interactions to be grouped into a single process instance. In analysis, this ID is used to distinctively identify each problem investigation journey from creation to closure. It enables the correlation of related incidents and the tracking of the problem's lifecycle through various support tiers. Why it matters It is the fundamental mandatory key required to group events into cases for any process mining analysis. Where to get Zendesk Ticket object, field 'id' where type is 'problem' Examples 1045293849921
	Source System SourceSystem	The name of the system where the data originated.
Description This attribute identifies the software platform from which the process data was extracted. In this context, it will consistently populate with 'Zendesk Support'. In analysis, particularly when combining data from multiple systems (e.g., Zendesk and Jira), this field allows analysts to filter or group data by its origin. It ensures data lineage and traceability in multi-system process views. Why it matters It ensures data lineage and supports multi-system process mining configurations. Where to get Hardcoded during extraction Examples Zendesk Support
	Start Time EventTimestamp	The specific date and time when an activity occurred.
Description This attribute records the exact moment an activity took place within the Zendesk system. It provides the temporal dimension required to sequence events correctly and calculate durations between steps. In analysis, this is critical for calculating cycle times, identifying delays, checking SLA compliance, and visualizing the process over time. Without accurate timestamps, it is impossible to understand the velocity of the problem resolution process. Why it matters It allows for the sorting of activities and the calculation of all time-based KPIs. Where to get Zendesk Ticket Audits, field 'created_at' Examples 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Assignee Name AssigneeName	The specific agent assigned to work on the problem.
Description This attribute contains the name of the individual user who is currently responsible for the problem record. It provides granular visibility into who performed specific actions. In analysis, this helps in understanding individual workload and performance. While group-level analysis is common, assignee-level data can highlight training needs or individuals who are particularly effective at resolving complex root causes. Why it matters It enables resource analysis at the individual level. Where to get Zendesk Ticket object, field 'assignee_id' (resolved to name) Examples John DoeJane SmithSystem
	Priority Priority	The urgency level assigned to the problem record.
Description This attribute indicates the relative importance of the problem, typically categorized as Low, Normal, High, or Urgent. It drives the expected service level agreements (SLAs) and resource allocation. In analysis, this is used to segment the process and compare performance across different urgency levels. For example, it helps verify if 'Urgent' problems are indeed being resolved faster than 'Low' priority ones, as required by the 'Root Cause Investigation Velocity' dashboard. Why it matters It is essential for segmenting cases to analyze SLA adherence and resource prioritization. Where to get Zendesk Ticket object, field 'priority' Examples UrgentHighNormalLow
	Problem Category ProblemCategory	The classification of the problem (e.g., Software, Hardware, Network).
Description This attribute categorizes the problem based on the affected service or technology stack. It is typically a custom dropdown field in Zendesk forms. In analysis, this is used for the 'Problem Categorization Accuracy' dashboard. Comparing this initial category against the final root cause helps identify if initial triage is accurately routing problems to the correct teams. Why it matters It allows for segmentation by technology or business service. Where to get Zendesk Ticket Custom Fields Examples DatabaseUI/UXNetwork Infrastructure
	Problem Status ProblemStatus	The current state of the problem record in its lifecycle.
Description This attribute shows the current status of the problem, such as New, Open, Pending, Solved, or Closed. It reflects the progress of the investigation. In analysis, this is used to filter for open versus closed cases. It is vital for the 'Stale Problem Record Monitoring' dashboard to identify which active cases are not progressing through the expected status lifecycle. Why it matters It allows for filtering cases by their completion state. Where to get Zendesk Ticket object, field 'status' Examples newopenpendingsolvedclosed
	Related Incident Count RelatedIncidentCount	The number of incident tickets linked to this problem record.
Description This attribute counts how many individual incident tickets are associated with this problem record. In Zendesk, this is managed via the 'problem_id' field on incident tickets linking back to this record. In analysis, this is the primary metric for 'Incident Correlation and Impact'. It helps prioritize problems that are affecting the largest number of users, guiding strategic decisions on which fixes will yield the highest ROI in terms of ticket volume reduction. Why it matters It indicates the magnitude and user impact of the problem. Where to get Zendesk Tickets API, count of tickets where type='incident' and problem_id=ThisID Examples 015342
	Root Cause Category RootCauseCategory	The identified underlying cause of the problem (e.g., Code Defect, Config Error).
Description This attribute captures the final diagnosis of what caused the problem. It is usually filled out during the 'Root Cause Identified' activity. In analysis, this is used to generate the 'Problem Categorization Accuracy' report and to analyze trends in system failures. It helps management understand if they should focus on code quality, infrastructure stability, or vendor management. Why it matters It enables the analysis of failure patterns and directs long-term improvement efforts. Where to get Zendesk Ticket Custom Fields Examples Software BugConfiguration ErrorUser Error
	SLA Due Date SlaDueDate	The target date and time by which the problem should be resolved.
Description This attribute represents the deadline for resolution based on the Service Level Agreement configuration. It is usually calculated based on the priority and the time the ticket was created. In analysis, this is compared against the actual resolution time to calculate 'Problem SLA Adherence Rate'. It powers the 'SLA Performance and Risk' dashboard by highlighting cases that are approaching or have exceeded their allotted time. Why it matters It is critical for measuring compliance and contractual performance. Where to get Zendesk Ticket Metrics or SLA Policies endpoint Examples 2023-12-01T17:00:00Z
	Support Group SupportGroup	The team or department currently assigned to the problem record.
Description This attribute identifies the specific group of agents responsible for the problem at a given point in time. It changes as the ticket is handed over from one team to another. In analysis, this is crucial for the 'Support Group Handover Analysis' dashboard. It allows for the measurement of performance per team, identification of bottlenecks during handovers, and analysis of resource workload distribution. Why it matters It enables organizational analysis and the identification of bottlenecks between departments. Where to get Zendesk Ticket object, field 'group_id' (resolved to name) Examples L2 SupportDatabase TeamNetwork Operations
	Change Request ID ChangeRequestId	The identifier of the change request linked to implement the fix.
Description This attribute links the problem record to a Change Management record (potentially in another system or a different ticket type). It signifies that a formal change process has been initiated. In analysis, this supports the 'Change Request Initiation Rate' dashboard. It helps track the transition from diagnosis to implementation, ensuring that identified root causes result in formal change actions. Why it matters It links the problem process to the change management process. Where to get Zendesk Ticket Custom Fields or Linked Tickets Examples CR-1002CHG00394
	Has PIR HasPostImplementationReview	Flags if a Post-Implementation Review was conducted.
Description This attribute indicates if the problem resolution process included a review phase. It is derived by checking if the 'Post-Implementation Review Conducted' activity exists in the case history. In analysis, this supports the 'Post Implementation Review Coverage' dashboard. It is a compliance metric ensuring that the organization is learning from its major problems. Why it matters It validates compliance with continuous improvement processes. Where to get Derived from presence of 'Post-Implementation Review Conducted' activity Examples truefalse
	Investigation Duration InvestigationDuration	The time taken from investigation start to root cause identification.
Description This calculated attribute measures the duration of the core diagnosis phase. It calculates the time difference between the 'Investigation Commenced' activity and the 'Root Cause Identified' activity. In analysis, this is the primary metric for 'Average Root Cause Analysis Duration'. It allows for the benchmarking of diagnostic speed across different support groups and problem categories. Why it matters It measures the efficiency of the diagnostic process. Where to get Calculated in Process Mining tool: Timestamp(Root Cause) - Timestamp(Investigation Start) Examples 48 hours5 days
	Is Stale IsStale	Flags if the problem has had no activity for over 14 days.
Description This calculated attribute identifies records that have not been updated recently. It compares the current date (or analysis date) with the last activity timestamp. In analysis, this powers the 'Stale Problem Record Monitoring' dashboard. It helps managers quickly isolate neglected cases that clutter the backlog and may require administrative closure or re-assignment. Why it matters It helps identify process waste and neglected work items. Where to get Calculated in Process Mining tool: (Now - LastDataUpdate) > 14 days Examples truefalse
	Knowledge Article ID KnowledgeArticleId	The ID of the knowledge base article created or linked to the problem.
Description This attribute stores the reference to a Zendesk Guide article or external knowledge item. It indicates that the knowledge gained from the problem has been captured. In analysis, the presence of this field is used to calculate the 'Knowledge Base Integration Rate'. It verifies that the organization is closing the learning loop by documenting solutions for future reference. Why it matters It measures the effectiveness of knowledge management processes. Where to get Zendesk Ticket Custom Fields or Linked Content Examples 360045889KB-2991
	Problem Subject ProblemSubject	The short summary or title of the problem record.
Description This attribute contains the text summary entered when the problem was created. It usually describes the symptom or the issue being investigated. In analysis, this provides context to the analyst when drilling down into specific cases. Text mining techniques can also be applied here to cluster similar problems or identify recurring topics that are not captured by structured category fields. Why it matters It provides human-readable context for individual cases. Where to get Zendesk Ticket object, field 'subject' Examples Unable to process payments in region EULatency spikes on login serverData export failing for admin users
	Workaround Active WorkaroundActive	A flag indicating if a workaround has been provided/published.
Description This boolean attribute indicates whether a temporary fix was documented for the problem. It is often derived from the presence of a 'Workaround Published' activity or a specific checkbox on the form. In analysis, this is used for the 'Workaround Publication Compliance' dashboard. It measures how often the support team provides immediate relief to users while the long-term investigation continues. Why it matters It is key for measuring the mitigation of user impact during investigations. Where to get Derived from presence of 'Workaround Published' activity or Custom Field Examples truefalse

Required Recommended Optional

Problem Management Activities

Capture these essential process steps and status changes to visualize the end to end flow from initial problem identification to permanent fix implementation.

8 Recommended 4 Optional

	Activity	Description
	Assigned to Support Group	The routing of the problem record to a specific technical team or department. This is tracked when the Group ID field on the ticket is updated.
Why it matters Critical for the Support Group Handover Analysis dashboard to measure wait times between departments. Where to get Monitor the 'group_id' field in the ticket audit log for changes. Capture Logged when transaction Group Assignment Change executed Event type explicit
	Investigation Commenced	Marks the transition from a passive 'New' state to an active working state. This indicates an agent has acknowledged the problem and begun diagnosis.
Why it matters Used to calculate Stale Problem Record metrics and is the starting point for the Average Root Cause Analysis Duration KPI. Where to get Inferred when the ticket status changes from 'New' to 'Open' or 'Pending'. Capture Compare status field before/after Event type inferred
	Permanent Fix Applied	Signifies that the technical solution has been deployed to the environment. This is usually tracked via a custom status transition or a specific tag before the ticket is fully solved.
Why it matters Essential for the Fix Implementation Efficiency dashboard to measure the time from diagnosis to deployment. Where to get Inferred from a specific tag (e.g., 'fix_deployed') or a custom status field if one exists. Capture Monitor tags or custom status dropdowns Event type inferred
	Problem Record Closed	The final lifecycle event where the ticket is locked and no further changes can be made. In Zendesk, this usually happens automatically 4 days after the Solved state.
Why it matters Marks the absolute end of the record's life and is used for data retention and historical reporting. Where to get Derived from the ticket status changing to 'Closed'. Capture Logged when status changes to Closed Event type explicit
	Problem Record Logged	The initial creation of the problem ticket within Zendesk Support. This event captures the timestamp when the problem was first recorded in the system, usually triggering the process instance.
Why it matters Establishes the start time for the End To End Resolution Cycle and serves as the baseline for all subsequent lead time metrics. Where to get Derived from the 'created_at' timestamp in the ticket object or the first entry in the ticket audit log. Capture Logged when transaction Ticket Created executed Event type explicit
	Resolution Verified	The formal marking of the problem as Solved. In Zendesk, this occurs when the standard system status is set to 'Solved', indicating the fix is verified and the case is complete.
Why it matters The primary endpoint for SLA Performance and Risk calculations and Problem SLA Adherence Rate. Where to get Derived from the ticket status changing to 'Solved'. Capture Logged when status changes to Solved Event type explicit
	Root Cause Identified	The point where the underlying cause of the problem is determined. This is typically captured when a custom 'Root Cause' text field or dropdown category is populated by the agent.
Why it matters A crucial milestone for the Root Cause Investigation Velocity dashboard and for measuring diagnosis efficiency. Where to get Monitor changes to custom fields labeled 'Root Cause', 'RCA', or 'Problem Source' for non-null values. Capture Compare custom field values for population Event type inferred
	Workaround Published	The action of documenting and sharing a temporary fix for the problem. In Zendesk, this is often captured via a specific tag or a custom checkbox field indicating a workaround is available.
Why it matters Supports the Workaround Publication Compliance dashboard, ensuring temporary relief is provided to users during long investigations. Where to get Monitor for the addition of a 'workaround_published' tag or a change to a custom boolean field named 'Workaround'. Capture Compare custom field or tag values Event type inferred
	Change Request Initiated	Indicates that a formal change management process has been triggered to fix the problem. This is often inferred when a 'Change Request ID' custom field is populated or a 'Change' type ticket is linked.
Why it matters Tracks the Change Request Initiation Rate and links Problem Management to Change Management workflows. Where to get Monitor for updates to a custom field like 'change_reference' or the creation of a 'problem_change' link type. Capture Monitor custom field for external ID entry Event type inferred
	Post-Implementation Review Conducted	Confirming that a retrospective review has been completed after the fix. This is typically a checkbox or date field updated by the process coordinator.
Why it matters Required for the Post-Implementation Review Frequency KPI to ensure compliance with quality standards. Where to get Monitor for updates to a custom checkbox 'PIR Completed' or date field 'PIR Date'. Capture Monitor custom field for completion Event type inferred
	Problem Investigation Reopened	Occurs when a problem record previously marked as Solved is returned to an Open or active state. This indicates a failed fix or rejected resolution.
Why it matters Supports the Problem Re-opening Rate KPI and helps identify quality issues in the resolution process. Where to get Inferred when the status transitions from 'Solved' back to 'Open', 'New', or 'Pending'. Capture Compare status field before/after Event type inferred
	Proposed Solution Drafted	The creation of a knowledge base article based on the problem investigation. This is inferred from the usage of the Zendesk Knowledge Capture app or linking a new article.
Why it matters Supports the Knowledge Base Integration Rate KPI, ensuring organizational learning. Where to get Monitor for events related to the 'Knowledge Capture' integration or tags like 'kcs_draft'. Capture Derive from specific system tags or link events Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Zendesk Support

Steps

Log in to your Zendesk instance and navigate to the Explore reporting interface via the product tray.
Click on the Queries folder (or Reports in newer versions) and select New query.
When prompted to select a dataset, choose Support followed by Updates History followed by Support: Updates History [default]. This dataset contains the event logs required for process mining rather than just current state data.
In the Metrics panel, add Count (Tickets) or Count (Updates) to ensure data is being pulled.
In the Filters panel, add a filter for Ticket > Ticket type and select Problem to restrict the dataset to the Problem Management process.
In the Rows panel, add the following attributes in this specific order to define the event log structure: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name, and Changes > Changes - Field name.
To create the Activity Name column, you must create a Standard Calculated Attribute. Click the Calculation icon on the right sidebar, select Standard calculated attribute, name it Activity Mapper, and paste the code provided in the Query section below.
Add this new Activity Mapper attribute to the Rows panel. Filter this attribute to exclude NULL values to remove irrelevant system noise.
Add additional attributes to the Rows panel for context: Ticket > Priority, Ticket > Group, Ticket > Status, and any custom fields required for root cause or category analysis (e.g., Ticket > Ticket tags or specific Custom Fields).
Set the time range in the Filters panel using Time - Timestamp > Update - Date to cover your desired analysis window (e.g., Last 6 Months).
Click the Visualization type icon and select Table. Ensure the table is unpivoted or flat if that option is available, or simply ensure all attributes are in the Rows section.
Export the result by clicking Export > CSV. Ensure the box for Keep attribute formatting is checked to preserve timestamp formats for ProcessMind.

Configuration

Dataset: Support: Updates History (Critical: Do not use the standard Tickets dataset as it only shows the current state).
Time Filter: Update - Date (Recommended: Last 90 to 180 days depending on volume).
Ticket Type: Filter strictly to Problem to avoid mixing Incidents and Service Requests.
Row Limit: Zendesk Explore exports are often limited to 50,000 rows. If your dataset exceeds this, utilize the Update - Date filter to export in smaller monthly chunks and merge them externally.
Custom Fields: Identify the specific Field IDs for Root Cause, Change Request, and Workaround in your specific Zendesk instance, as these are not standard system fields.
System Permissions: Requires an Explore Viewer or Explore Professional license.

a Sample Query config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Steps

Prerequisite Confirmation: Ensure your organization has the Zendesk Data Sharing add-on enabled. Confirm you have read-only access credentials for the replicated Zendesk database, which is typically hosted on Snowflake or Amazon Redshift.
Connect to the Database: Use your preferred SQL client (such as DBeaver, DataGrip, or the native Snowflake/Redshift web interface) to establish a connection to your Zendesk data warehouse using the provided credentials.
Identify Custom Fields: Before running the query, you must identify the unique IDs for the custom fields used in your Problem Management process. Navigate to Admin Center in Zendesk, go to Objects and rules > Tickets > Fields. Find the fields for 'Root Cause', 'Change Request ID', 'Workaround Published', 'Permanent Fix Applied', and 'Post-Implementation Review' to get their specific field IDs. These will be used to replace the placeholders in the query.
Review the SQL Query: The provided query uses a Common Table Expression (CTE) named ProblemTickets to first select and filter all problem records. This improves performance and readability. The main part of the query then uses UNION ALL to combine the results of 12 separate SELECT statements, one for each required activity.
Customize the Query: Open a new query editor and paste the complete SQL script. Modify the placeholders within the script:
- In the ProblemTickets CTE, set the desired date range by replacing '[YYYY-MM-DD]'.
- For each activity that relies on a custom field, replace the placeholder IDs (e.g., [Your 'Root Cause Category' field_id], [Your 'Change Request ID' field_id]) with the actual IDs you identified in step 3.
Execute the Query: Run the modified SQL script against the database. The execution time will vary depending on the date range and the volume of ticket data.
Investigate 'Proposed Solution Drafted' Logic: The query assumes that drafting a solution is captured by populating a custom field named [Your 'KB Article ID' field_id]. If your process differs, for example, using a specific tag or comment, you will need to adjust this part of the query accordingly.
Data Validation: Once the query completes, perform a brief review of the results. Check for a reasonable number of rows, ensure all columns are present, and scan for any unexpected NULL values in critical columns like ProblemRecordId and EventTimestamp.
Export the Event Log: Export the entire result set from your SQL client to a CSV file. Ensure the file uses UTF-8 encoding and that the column headers match the attribute names required by your process mining tool.
Prepare for Upload: Before uploading, check the CSV file for any formatting issues. Make sure date and time values in the EventTimestamp column are in a consistent format, such as YYYY-MM-DD HH24:MI:SS.

Configuration

Prerequisites: This extraction requires the Zendesk Data Sharing add-on and direct SQL access to the replicated data in a Snowflake or Amazon Redshift instance.
Ticket Type Filter: The query is pre-configured to only analyze tickets where the type is 'problem'. This is critical for isolating the Problem Management process from incidents and other ticket types.
Date Range Filtering: It is highly recommended to filter the data for a specific period to manage performance. The query includes a placeholder created_at >= '[YYYY-MM-DD]' in the initial CTE. For a first analysis, a range of 3 to 6 months is typical.
Custom Field Configuration: This extraction is heavily dependent on your specific Zendesk configuration. You must identify and insert the correct field_id for custom fields that track activities like 'Root Cause Identified', 'Change Request Initiated', and 'Workaround Published'. The query will fail or return no data for these activities if the placeholder IDs are not replaced.
Data Latency: The data in the replicated database is not real-time. There is typically a delay of a few hours between an event occurring in Zendesk and it appearing in the data warehouse. Keep this in mind when analyzing very recent activity.

a Sample Query sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Steps

Prerequisites: Ensure you have Python 3.6+ installed on your system. Install the required requests and pandas libraries by running pip install requests pandas in your terminal or command prompt.
Generate Zendesk API Token: Log in to Zendesk Support as an administrator. Navigate to Admin Center > Apps and integrations > APIs > Zendesk API. Under the Token Access section, click 'Add API token' to create a new token. Copy this token immediately and store it securely, as it will not be shown again.
Configure the Python Script: Create a new Python file (e.g., extract_zendesk_problems.py) and copy the complete script provided in the Query section into this file. Update the placeholder variables at the top of the script: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME. For the initial run, set START_TIME to the Unix timestamp of the desired start date for your extraction.
Map Custom Field IDs: Identify the numeric IDs for the custom fields used in your Problem Management process. You can find these by navigating to Admin Center > Objects and rules > Tickets > Fields and inspecting the URL or field properties. Update the CUSTOM_FIELD_MAPPING dictionary in the script with your specific IDs.
Execute the Script: Run the script from your terminal using the command python extract_zendesk_problems.py. The script will begin fetching data from the Zendesk Incremental Export API.
Monitor Execution: The script will print its progress, including the number of tickets processed and the current timestamp it is fetching. It will automatically handle API rate limits by pausing when necessary.
Data Retrieval and Transformation: The script first retrieves all problem tickets created or updated since the START_TIME. For each problem ticket, it then fetches the complete audit trail, which contains all historical changes.
Event Log Generation: The script processes each audit event, mapping field changes (like status, group, or custom field updates) to the defined business activities. It also fetches and caches user and group names to enrich the data.
Handling Incremental Loads: After the initial full load, for subsequent runs, update the START_TIME variable to the end_time printed at the end of the previous successful run. This ensures you only pull new and updated data without duplication.
Review the Output: Once the script completes, it will generate a file named zendesk_problem_event_log.csv in the same directory. This CSV file contains the structured event log ready for analysis.
Prepare for Upload: Open the CSV file in a spreadsheet tool to verify its contents. Ensure all required columns (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) are present and correctly populated before uploading to ProcessMind.

Configuration

Zendesk API Credentials: The script requires your Zendesk subdomain, the email address of the user associated with the API token, and the API token itself for authentication.
Start Time: The START_TIME variable is a Unix epoch timestamp that defines the starting point for the data extraction. For the first run, set this to a date in the past (e.g., 6 months ago) to get historical data. For subsequent runs, use the end time from the previous run to fetch data incrementally.
Custom Field Mapping: The CUSTOM_FIELD_MAPPING dictionary is critical. You must update the placeholder IDs with the actual custom field IDs from your Zendesk instance to correctly capture activities like 'Workaround Published' and 'Root Cause Identified'.
Ticket Type Filter: The script is hardcoded to only process tickets where the type is 'problem'. This ensures that incidents, tasks, and questions are excluded from the problem management event log.
API Rate Limiting: The script includes a basic time.sleep(60) function to handle 429 'Too Many Requests' errors. This pause duration may need to be adjusted depending on your Zendesk plan and the volume of data being extracted.
Prerequisites: A Python 3 environment with the requests and pandas libraries is necessary to run the script. The API token must be associated with an account that has permission to read ticket data.

a Sample Query python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

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

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

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 str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

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 str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    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', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

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

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_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">"Extraction complete. Event log saved to {output_filename}")

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

Your Problem Management Data Template

Your Problem Management Data Template

Problem Management Attributes

Problem Management Activities

Extraction Guides

Zendesk Explore Updates History Export

Steps

Configuration

a Sample Query config

SQL Query via Zendesk Data Sharing

Steps

Configuration

a Sample Query sql

Python Extraction using Incremental Export API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize Your Problem Management for Faster IT Fixes

Your Problem Management Data Template

Your Problem Management Data Template

Problem Management Attributes

Problem Management Activities

Extraction Guides

Zendesk Explore Updates History Export

Steps

Configuration

a Sample Query config

SQL Query via Zendesk Data Sharing

Steps

Configuration

a Sample Query sql

Python Extraction using Incremental Export API

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Optimize Your Problem Management for Faster IT Fixes