> Continuous Process Improvement > Incident Management > Jira Service Management > Data Template

Data Template: Incident Management

Jira Service Management

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

Your Incident Management Data Template

This template offers a structured approach to gathering the essential data for analyzing your incident management process. It outlines the crucial attributes to collect, the key activities to track, and provides practical guidance for extracting this information from your source system. This ensures you have all the necessary components to start optimizing your incident resolution workflows.

Recommended attributes to collect
Key activities to track
Extraction guidance for Jira Service Management

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

Download Template

Incident Management Attributes

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

5 Required 7 Recommended 12 Optional

	Name	Description
	Activity ActivityName	The name of the specific event or status change that occurred for the incident.
Description The Activity represents a distinct step or event in the incident management lifecycle, such as 'Incident Created', 'Incident Assigned', or 'Resolution Proposed'. These are typically derived from status transitions or specific update events recorded in the Jira issue's history or changelog. Analyzing the sequence and duration of these activities is the primary goal of process mining, revealing the actual process flow, bottlenecks, and deviations. Why it matters Activities form the backbone of the process map, allowing for visualization and analysis of the incident lifecycle. Where to get Derived from the Jira issue history and changelog data, capturing status transitions and key field updates. Examples Incident AssignedInvestigation StartedIncident Resolved
	Incident ID IncidentId	The unique identifier for each incident ticket in Jira Service Management.
Description The Incident ID, often referred to as the Issue Key in Jira, serves as the primary unique identifier for each reported incident. It links all associated activities, comments, and status changes from the moment of creation through to final closure. In process mining, this ID is essential for reconstructing the end-to-end lifecycle of every individual incident, allowing for a comprehensive analysis of the entire process. Why it matters This is the core identifier used to correlate all related events into a single case, making it the foundation for any process mining analysis. Where to get This is the standard 'Key' field for an issue in Jira Service Management (e.g., 'ITSM-123'). Examples INC-10234HELPDESK-5678OPS-9901
	Start Time EventTimestamp	The exact date and time when the activity occurred.
Description This attribute records the timestamp for every activity in the incident's lifecycle. It is crucial for calculating durations, cycle times, and wait times between different steps in the process. Accurate timestamps allow for detailed performance analysis, SLA monitoring, and bottleneck identification. All performance metrics, such as resolution time and diagnosis duration, are derived from these timestamps. Why it matters Timestamps are essential for calculating all time-based metrics, understanding process duration, and discovering performance bottlenecks. Where to get This is the 'created' date associated with each entry in the Jira issue's changelog or history. Examples 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Last Data Update LastDataUpdate	The timestamp indicating the last time the data was refreshed from the source system.
Description This attribute records when the dataset was last updated. It provides critical context to anyone analyzing the process, ensuring they are aware of the data's freshness. This is especially important for ongoing monitoring dashboards where up-to-date information is crucial for making timely decisions. The value is typically the same for all events within a single data extraction batch. Why it matters Informs users about the timeliness of the data, which is crucial for the relevance and accuracy of the analysis. Where to get This is the timestamp of the data extraction run, added during the data transformation process. Examples 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Source System SourceSystem	The system from which the data was extracted.
Description This attribute identifies the origin of the data, which in this case is Jira Service Management. It is particularly useful in environments where data from multiple systems is combined for a holistic process view. Specifying the source system ensures data lineage is clear and helps in diagnosing data quality or extraction issues. For this model, the value would be static. Why it matters Provides essential context about data origin, ensuring clarity and traceability, especially in multi-system analysis. Where to get This is a static value that should be added during the data extraction process. Examples Jira Service ManagementJira Cloud
	Assignee Assignee	The user currently assigned to work on the incident.
Description The Assignee is the individual agent or user responsible for the incident at a given point in time. Tracking changes to the assignee is critical for analyzing handoffs, understanding workload distribution, and identifying which individuals are involved in specific process steps. This attribute helps answer questions about individual performance and resource allocation within the support teams. Why it matters Helps track individual workload, identify bottlenecks related to specific agents, and analyze the impact of handoffs on resolution time. Where to get The standard 'Assignee' field on a Jira issue. Examples John SmithEmily JonesServiceDeskAgent1
	Assignment Group AssignmentGroup	The team or group responsible for handling the incident.
Description The Assignment Group represents the team assigned to the incident. This could be a support tier like 'L1 Helpdesk', a specialized team like 'Network Operations', or a development team. Analyzing transitions between assignment groups is key to understanding process escalations and handoffs. It allows for the measurement of team performance, identification of team-level bottlenecks, and analysis of inter-team dependencies. Why it matters Crucial for analyzing team performance, throughput, and the flow of work between different support tiers or specialized groups. Where to get This is often implemented as a custom field in Jira, such as 'Team' or 'Assignment Group'. It can sometimes be derived from Jira Components or Project Roles. Examples Tier 1 SupportInfrastructure TeamDatabase Administrators
	Created Date CreatedDate	The date and time when the incident was first created in the system.
Description This attribute marks the official start of the incident lifecycle. It is the baseline timestamp from which overall metrics like total resolution time are calculated. The creation date is a static value for each incident and serves as the starting point for the entire case in the process mining analysis. Why it matters Acts as the starting point for all end-to-end cycle time calculations and SLA measurements. Where to get The standard 'Created' field on a Jira issue. Examples 2023-10-26T09:58:12Z2023-11-01T15:20:05Z
	Priority Priority	The priority level assigned to the incident, indicating the urgency of resolution.
Description Priority determines the required speed for addressing an incident. It is often a combination of impact and urgency and directly influences SLA targets. Analyzing incidents by priority helps to understand if high-priority incidents are being handled faster than low-priority ones and if prioritization is being applied consistently. It's a critical dimension for filtering and comparing process performance. Why it matters Essential for SLA performance analysis and for verifying that resources are correctly allocated to the most critical incidents. Where to get The standard 'Priority' field on a Jira issue. Examples HighestHighMediumLow
	Resolution Cycle Time IncidentResolutionCycleTime	The total time elapsed from incident creation to resolution.
Description This is a calculated metric representing the duration from the 'CreatedDate' to the 'ResolutionDate'. It is one of the most important KPIs in incident management, directly measuring the efficiency of the entire process. Analyzing this metric across different dimensions like priority, assignment group, or component helps to identify which factors have the biggest impact on performance. Why it matters Directly measures the end-to-end efficiency of the incident management process and is a primary KPI for performance tracking. Where to get Calculated as ('ResolutionDate' - 'CreatedDate'). Examples 2h 30m1d 4h5d 1h 15m
	Resolution Date ResolutionDate	The date and time when the incident was marked as resolved.
Description This attribute captures the timestamp when the incident was first moved into a resolved status. It marks the end of the active work phase and is the endpoint for calculating the Time to Resolution. Comparing the resolution date with the creation date provides the primary measure of process efficiency. It is also a key component in determining SLA compliance. Why it matters Marks the end of the resolution process, enabling the calculation of total cycle time and SLA performance. Where to get The standard 'Resolved' field on a Jira issue. Examples 2023-10-28T11:20:30Z2023-11-02T10:00:00Z
	Status Status	The current stage of the incident in its lifecycle.
Description The Status field indicates the current state of an incident within the defined workflow, such as 'Open', 'In Progress', 'Pending Customer', or 'Resolved'. Status changes are the primary source for generating the activity log for process mining. Analyzing the time spent in each status is fundamental to identifying bottlenecks and understanding where incidents spend the most time. Why it matters Directly reflects the incident's progress and is the primary source for identifying process steps and wait times. Where to get The standard 'Status' field on a Jira issue. Examples In ProgressWaiting for customerResolvedClosed
	Component Component	The system, application, or part of the infrastructure affected by the incident.
Description Components are sub-sections of a Jira project used to group issues into smaller parts, such as 'User Interface', 'Database', or 'API'. Analyzing incidents by component helps to pinpoint which parts of a system are most prone to issues. This information is valuable for root cause analysis and can guide efforts for service improvement or technical debt reduction. Why it matters Allows for filtering and analysis based on the specific product or system area affected, helping to identify technology hotspots. Where to get The standard 'Components' field on a Jira issue. Examples Authentication ServiceReporting DashboardMobile App
	Customer Request Type CustomerRequestType	The specific type of request submitted by the customer through the service portal.
Description This field categorizes requests from the customer's point of view, as presented on the Jira Service Management portal (e.g., 'Report a system issue'). It provides a user-friendly classification of the incident, which can differ from the internal 'Issue Type'. Analyzing this attribute can offer insights into how customers perceive and report issues, helping to improve portal design and service offerings. Why it matters Provides a customer-centric view of incident categories, which is useful for analyzing demand and improving the customer experience. Where to get The 'Customer Request Type' field, specific to Jira Service Management projects. Examples Get IT help > Report a system issueEmail > Access request
	Handoff Count HandoffCount	The number of times the incident was reassigned to a different group or user.
Description This calculated metric counts the number of times the 'Assignee' or 'AssignmentGroup' field changed during the incident's lifecycle. A high handoff count often indicates process inefficiency, lack of first-call resolution, or knowledge gaps, leading to longer resolution times. Analyzing this KPI helps to streamline the assignment process and improve team collaboration. Why it matters Quantifies process friction and inefficiency caused by reassignments, helping to identify opportunities for process improvement. Where to get Calculated by counting the number of changes to the 'Assignee' or 'AssignmentGroup' field in the issue changelog. Examples 015
	Is Rework IsRework	A flag indicating if the incident has undergone rework, such as being reopened.
Description This calculated boolean attribute identifies incidents that have been sent back to a previous stage in the process, most commonly by being reopened after they were resolved. Rework loops are a significant source of inefficiency and customer dissatisfaction. This flag allows for easy quantification of the rework rate and helps to focus analysis on why incidents are failing to be resolved correctly the first time. Why it matters Highlights process quality issues and inefficiencies by flagging incidents that require repeated work, directly supporting rework analysis. Where to get Calculated by detecting specific sequences of status transitions in the event log, such as 'Resolved' -> 'Reopened'. Examples truefalse
	Issue Type IssueType	The type of issue, such as Incident, Service Request, or Problem.
Description Jira uses Issue Types to distinguish between different kinds of tasks. In an Incident Management context, the primary type is 'Incident', but others like 'Sub-task' might also be relevant. This attribute is crucial for filtering the dataset to include only incidents, ensuring that the process mining analysis is focused on the correct process. Why it matters Ensures the analysis is correctly scoped to incidents, separating them from other work types like service requests or changes. Where to get The standard 'Issue Type' field on a Jira issue. Examples IncidentIT HelpBug
	Linked Problem ID LinkedProblemId	The identifier of a problem ticket that is linked to this incident.
Description Incidents that are symptoms of a larger, underlying issue are often linked to a Problem ticket. This field stores the ID of that associated Problem. Analyzing these links helps to understand the relationship between incidents and problems, measure the effectiveness of the problem management process, and identify recurring incidents that require a permanent fix. Why it matters Connects incidents to underlying problems, enabling analysis of how effectively the organization addresses root causes to prevent future incidents. Where to get This information is stored in the 'Issue Links' section of a Jira issue. Examples PROB-123PROB-456None
	Reporter Reporter	The user who initially created or reported the incident.
Description The Reporter is the individual, often an end-user or another system, who first logged the incident. Analyzing incidents by reporter can help identify users or departments that frequently experience issues. It can also be used to understand communication patterns, especially when analyzing activities like 'Waiting for Customer' and 'Customer Responded'. Why it matters Helps to analyze incident sources, identify patterns related to specific users or departments, and understand customer interaction delays. Where to get The standard 'Reporter' field on a Jira issue. Examples Alice JohnsonBob Williamsmonitoring-tool@example.com
	Resolution Resolution	The final outcome or reason for resolving the incident.
Description The Resolution field explains why an incident was moved to a resolved state. Common resolutions include 'Fixed', 'Duplicate', 'Won't Do', or 'Cannot Reproduce'. Analyzing the distribution of resolution types can provide insights into the quality of incoming reports and the effectiveness of the resolution process. For example, a high number of 'Duplicate' resolutions may indicate a problem in the incident creation or triage stage. Why it matters Gives context to the outcome of an incident, helping to categorize resolutions and identify trends in how incidents are closed. Where to get The standard 'Resolution' field on a Jira issue. This field is typically set when an issue is transitioned to a 'Done' status category. Examples DoneFixedDuplicateWon't Fix
	Root Cause Category RootCauseCategory	The classification of the underlying root cause of the incident.
Description This attribute captures the fundamental reason why the incident occurred, such as 'Software Defect', 'Hardware Failure', or 'User Error'. It is typically populated after investigation and is essential for effective problem management and prevention of future incidents. Analyzing root cause categories helps to identify systemic weaknesses and prioritize improvement initiatives. A high rate of 'Unknown' root causes may signal a need for better investigation processes. Why it matters Enables root cause analysis, helping to move from a reactive to a proactive approach by identifying and addressing the sources of incidents. Where to get This is almost always a custom field in Jira. The name and options are highly dependent on the organization's specific configuration. Examples Configuration ErrorNetwork OutageSoftware Bug
	Severity Severity	The measure of the business impact of the incident.
Description Severity defines how much impact an incident has on the business, from a single user being affected to a critical system outage. While Priority dictates the order of work, Severity informs the overall business impact. Analyzing by severity helps in understanding the process performance for incidents that matter most to the business and is often used in combination with Priority for a more nuanced analysis. Why it matters Provides a view of business impact, allowing for analysis focused on the most damaging incidents to business operations. Where to get Typically a custom field in Jira, as it is not a standard system field. Consult Jira Service Management project configuration. Examples CriticalMajorMinorTrivial
	SLA Breach SlaBreach	A flag indicating whether the incident resolution time exceeded the SLA target.
Description This calculated boolean attribute indicates if an incident has breached its 'Time to Resolution' SLA. It is true if the 'IncidentResolutionCycleTime' is greater than the 'TimeToResolutionTarget'. This flag simplifies analysis and visualization, allowing for easy filtering and aggregation to calculate the overall SLA Breach Rate KPI. It is the key outcome measure for the SLA Performance Monitoring dashboard. Why it matters Provides a clear, binary outcome for SLA performance, making it simple to calculate breach rates and identify problem areas. Where to get Calculated as ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget'). Examples truefalse
	Time To Resolution Target TimeToResolutionTarget	The SLA target duration for resolving the incident.
Description This attribute defines the expected maximum time within which an incident of a certain priority or type should be resolved. It is the benchmark against which actual resolution time is measured to determine SLA compliance. This value is typically set dynamically based on rules considering factors like priority, severity, or issue type. It is fundamental for any SLA performance monitoring dashboard. Why it matters Provides the benchmark for measuring SLA compliance, forming the basis for the Incident SLA Breach Rate KPI. Where to get This is derived from the SLA configuration within Jira Service Management. The specific goal (e.g., 'Time to resolution') must be identified. Examples 4h8h3d

Required Recommended Optional

Incident Management Activities

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

7 Recommended 8 Optional

	Activity	Description
	Incident Closed	Represents the final, administrative closure of the incident ticket after it has been resolved and verified. This is inferred from the status transition to 'Closed'.
Why it matters This is the terminal event of the process. Analyzing the time between 'Resolved' and 'Closed' can reveal delays in administrative cleanup or user confirmation processes. Where to get Inferred from the issue's status change history. The event corresponds to the timestamp when the status transitions to the final 'Closed' state. Capture Identify the timestamp of the status transition to 'Closed'. Event type inferred
	Incident Created	Marks the official start of the incident lifecycle when an incident report is submitted and a new issue is created in Jira. This event is captured explicitly when a new issue of the 'Incident' type is logged in the system.
Why it matters This is the primary start event for the process. Analyzing the time from this activity to resolution is fundamental for measuring overall cycle time and SLA adherence. Where to get This is an explicit event captured from the 'created' timestamp of the incident issue in Jira. The issue creation event is logged in the issue's history. Capture Use the issue creation timestamp. Event type explicit
	Incident Reassigned	Occurs when an incident is transferred from one agent or group to another after the initial assignment. This event is inferred from any change in the 'Assignee' or 'Assigned Group' field.
Why it matters Tracking reassignments is crucial for handoff analysis. A high number of reassignments often indicates process inefficiencies, knowledge gaps, or incorrect initial routing, leading to resolution delays. Where to get Inferred from the issue history by detecting any update to the 'Assignee' field after it was first populated. Each change constitutes a reassignment event. Capture Identify subsequent changes to the 'Assignee' field after the initial assignment. Event type inferred
	Incident Resolved	This activity marks the confirmation that the incident has been successfully resolved and the service is restored. It often coincides with the transition to the 'Resolved' status.
Why it matters This is the primary success milestone in the process. The duration until this point is the most common KPI, representing the Time to Resolution (TTR). Where to get Inferred from the status change to 'Resolved'. In many workflows, this is the same event as 'Resolution Proposed', representing the main resolution point. Capture Identify the timestamp of the status transition to 'Resolved'. Event type inferred
	Investigation Started	Indicates that an assigned agent has started actively working on diagnosing the incident. This is typically inferred when the incident issue status is transitioned from 'Open' or 'New' to 'In Progress'.
Why it matters This key milestone marks the beginning of active resolution efforts. Measuring the time until this activity helps identify initial queuing delays and resource availability issues. Where to get Inferred from the issue's status change history. The event timestamp is when the status transitions to a state representing active work, such as 'In Progress'. Capture Identify the timestamp of the status transition to 'In Progress'. Event type inferred
	Resolution Proposed	This activity indicates that a resolution has been identified and implemented, and the incident is awaiting confirmation or final validation. It's inferred from the status transition to 'Resolved'.
Why it matters This is a major milestone that signifies the end of active work by the support team. It is often the event that stops the SLA clock. Where to get Inferred from the issue's status change history. The event timestamp is when the status transitions to 'Resolved' or an equivalent state. Capture Identify the timestamp of the status transition to 'Resolved'. Event type inferred
	Waiting For Customer	Marks a point where the support team is awaiting information or action from the customer. This is inferred from a status transition to a dedicated waiting status like 'Waiting for customer'.
Why it matters Isolating this 'on-hold' time is critical for accurate SLA measurement, as it is often excluded from resolution time calculations. It helps analyze customer response delays. Where to get Inferred from the issue's status change history. The event corresponds to the timestamp when the status changes to 'Waiting for customer' or a similar state. Capture Identify the timestamp of the status transition to 'Waiting for customer'. Event type inferred
	Comment Added	Represents any communication or note-taking event where a user adds a comment to the incident ticket. This is an explicit event captured every time a comment is posted.
Why it matters Analyzing comment frequency can provide insights into communication patterns, collaboration efficiency, and the complexity of an incident. It can highlight incidents requiring excessive communication. Where to get This is an explicit event. Jira stores every comment with a timestamp and author, available through the issue's comment history or the API. Capture Use the timestamp of each comment added to the issue. Event type explicit
	Customer Responded	Indicates that the customer has provided the requested information, and the incident can proceed. This is inferred when the status moves out of 'Waiting for customer' back into an active status.
Why it matters This activity marks the end of a customer-induced delay. Analyzing the duration between 'Waiting For Customer' and this event reveals the average customer response time. Where to get Inferred from the issue's status change history. The event occurs when the status transitions from 'Waiting for customer' to a status like 'In Progress', often triggered by the customer adding a comment. Capture Detect status change from 'Waiting for customer' to 'In Progress'. Event type inferred
	Escalated To Specialist Team	Signifies that the incident has been escalated to a specialized team (e.g., Tier 2, Development) for advanced support. This is inferred from a change in a custom 'Support Team' field or a specific reassignment.
Why it matters Highlights incidents that require specialized knowledge and tracks the flow between different support levels. This helps identify bottlenecks within specialized teams and analyze escalation patterns. Where to get Inferred from the issue history by tracking changes to a custom field representing the assigned team or by identifying an 'Assignee' change to a member of a known specialist group. Capture Detect a change in a custom field for 'Assigned Team' or specific assignee changes. Event type inferred
	Incident Assigned	This activity signifies the initial assignment of the incident to a support agent or group for handling. It is captured by tracking the first time the 'Assignee' or 'Assigned Group' field is populated.
Why it matters Measures the initial response and assignment time, which is a key component of SLA metrics. It helps identify delays before active investigation begins. Where to get Inferred from the issue history by identifying the first change to the 'Assignee' field where the previous value was 'Unassigned'. Capture Detect the first update to the 'Assignee' field in the issue history. Event type inferred
	Incident Prioritized	Represents the setting of the incident's priority and/or severity, which dictates its urgency and business impact. This is typically inferred from the first time the 'Priority' or 'Severity' fields are populated or updated after creation.
Why it matters Tracking prioritization helps analyze if incidents are assessed promptly and consistently. Delays in this step can directly impact SLA calculations and resource allocation. Where to get Inferred from the issue history log, which tracks changes to all fields. Look for the first update to the 'Priority' or a custom 'Severity' field after the issue creation event. Capture Detect the first change to the 'Priority' field in the issue history. Event type inferred
	Incident Reopened	Represents a situation where a previously resolved incident is reactivated because the issue reoccurred or the fix was ineffective. This is inferred by a status change from 'Resolved' or 'Closed' back to an open status.
Why it matters Reopened incidents are a direct measure of resolution quality and a primary indicator of rework. Analyzing these events helps identify premature closures and ineffective solutions. Where to get Inferred from the issue's status change history. The event is logged when the status moves from a terminal state like 'Resolved' or 'Closed' back to 'Open' or 'In Progress'. Capture Detect status change from 'Resolved' or 'Closed' to an open status. Event type inferred
	Linked To Problem Ticket	Occurs when an incident is linked to a 'Problem' issue for root cause analysis. This is an explicit event captured when a 'relates to' or 'caused by' link is created to a Problem issue type.
Why it matters Tracking this link is essential for understanding how effectively the organization transitions from incident mitigation to root cause analysis and prevention. Where to get This is an explicit event logged in the issue's link history. Each link creation has a timestamp and can be filtered for links to the 'Problem' issue type. Capture Use the timestamp of the creation of an issue link to a 'Problem' issue type. Event type explicit
	Workaround Provided	Represents the implementation of a temporary fix to restore service while a permanent solution is being developed. This can be inferred from a status change or a specific comment.
Why it matters Measuring the time to provide a workaround is a key indicator of service restoration speed. It helps differentiate between temporary mitigation and permanent resolution. Where to get This is often inferred. It could be a transition to a 'Workaround Provided' status or the addition of a public comment containing specific keywords like 'workaround'. Capture Identify a specific status transition or keyword in a comment. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Jira Service Management

Steps

Prerequisite Check: This method requires a Jira Marketplace App like 'Better Excel Exporter' or 'Exporter for Jira', as the standard built-in CSV export does not include the detailed issue history (changelog) required to reconstruct the process timeline. Verify that such an app is installed and you have permissions to use it.
Navigate to Advanced Issue Search: Log into your Jira Service Management instance. In the top navigation bar, select 'Filters' and then 'Advanced issue search'. This will open the Issue Navigator with the JQL query editor.
Execute JQL Query: In the JQL query bar, enter the provided JQL query to select all incident tickets within a specified date range. This will form the basis of your raw data export. A typical query would be issuetype = Incident AND project = "[Your JSM Project Key]" AND created >= "-180d".
Configure Export Columns: Locate the export option, which may be labeled 'Export' or be under an app-specific menu. Configure the export to create a CSV file. It is critical to include the following fields: Issue Key, Created, Resolved, Status, Priority, Assignee, and most importantly, the full Changelog or History. Exporter apps often allow you to export each changelog item as a separate row, which is the ideal format for transformation.
Export the Raw Data: Execute the export and download the resulting CSV file. This file will contain the raw, untransformed data, likely with one row per issue change rather than one row per issue.
Prepare the Transformation Environment: The provided Python script is required to transform the raw export into a valid event log. Ensure you have Python and the pandas library installed on your system. You can install pandas by running pip install pandas in your terminal.
Run the Transformation Script: Save the provided Python script to a file (e.g., transform_jira_log.py). Place the exported CSV file in the same directory. Modify the script to specify the correct input and output filenames.
Execute the Script: Run the script from your terminal using the command: python transform_jira_log.py. The script will process the raw data and generate a new CSV file named jira_incident_event_log.csv, formatted correctly for process mining.
Review and Upload: Open the final jira_incident_event_log.csv file to validate its contents. Once confirmed, this event log is ready to be uploaded to your process mining tool.

Configuration

JQL Query: The JQL (Jira Query Language) query is the primary filter for selecting data. Key filters include:
- issuetype = Incident: Ensures you only extract incident tickets.
- project = "[Your JSM Project Key]": Restricts the data to a specific service desk project. Replace the placeholder with your project's key (e.g., 'ITSUP').
- created >= "-180d": Sets the date range for the extraction. A period of 3-6 months ('-90d' to '-180d') is recommended to balance data volume and insight.
Export App Configuration: The Marketplace exporter app must be configured to output the changelog. The ideal output format is one row per change, with columns indicating the Issue Key, the field that was changed, the old value, the new value, and the timestamp of the change.
Required Fields for Export: Ensure the export includes at least Issue Key, Created, Resolved, Creator, Priority, Status, Assignee, [Assignment Group Custom Field], [Support Team Custom Field], and the full Changelog history (timestamp, author, field, from string, to string).
Prerequisites: This method requires a Jira Service Management license, user permissions to access the Issue Navigator and run JQL queries, and an installed Jira Marketplace app capable of exporting detailed issue changelogs.

a Sample Query config

import pandas as pd
import numpy as np
from datetime import datetime

# --- Configuration ---
# Specify the path to your raw CSV file exported from Jira
# This file should have one row per changelog item.
INPUT_CSV_PATH = '[Your-Jira-Export-File].csv'
# Specify the desired name for the final event log file
OUTPUT_CSV_PATH = 'jira_incident_event_log.csv'

# --- Main Transformation Logic ---
def transform_jira_to_event_log(input_path, output_path):
    """Transforms a detailed Jira changelog export into a process mining event log."""
    try:
        # Load the raw data, assuming common column names from Jira exporters.
        # Adjust column names here to match your specific export file.
        # 'Issue Key' -> Incident ID
        # 'Date' -> Timestamp of the change
        # 'Field' -> The field that was changed (e.g., 'status', 'assignee')
        # 'Original value' -> Old value
        # 'New value' -> New value
        # You must also include columns for 'Created', 'Resolved', 'Priority', etc., at the issue level.
        df_raw = pd.read_csv(input_path)
    except FileNotFoundError:
        print(f"Error: Input file not found at '{input_path}'. Please check the path.")
        return

    # Standardize column names for easier processing
    # Replace these with the actual column names from your export
    column_map = {
        'Issue key': 'IncidentId',
        'History Date': 'EventTimestamp',
        'History Author': 'Author',
        'Field': 'ChangedField',
        'From String': 'OldValue',
        'To String': 'NewValue',
        'Created': 'CreatedDate',
        'Resolved': 'ResolutionDate',
        'Priority': 'Priority',
        'Status': 'Status',
        'Assignee': 'Assignee',
        # Add mappings for your custom fields if necessary
        # '[Your Assignment Group Field]': 'AssignmentGroup'
    }
    df_raw.rename(columns=column_map, inplace=True)

    # Ensure timestamp columns are in datetime format
    df_raw['EventTimestamp'] = pd.to_datetime(df_raw['EventTimestamp'], errors='coerce')
    df_raw['CreatedDate'] = pd.to_datetime(df_raw['CreatedDate'], errors='coerce')
    df_raw['ResolutionDate'] = pd.to_datetime(df_raw['ResolutionDate'], errors='coerce')

    events = []
    # Group by incident to process each ticket's lifecycle
    for incident_id, group in df_raw.groupby('IncidentId'):
        # Sort changes chronologically
        group = group.sort_values(by='EventTimestamp').reset_index()

        # Get issue-level attributes from the first record
        first_record = group.iloc[0]
        created_date = first_record['CreatedDate']
        resolved_date = first_record['ResolutionDate']

        # 1. Incident Created Event
        events.append({
            'IncidentId': incident_id,
            'ActivityName': 'Incident Created',
            'EventTimestamp': created_date,
            'Assignee': first_record.get('Assignee'),
            'AssignmentGroup': first_record.get('AssignmentGroup'),
            'Status': first_record.get('Status'),
            'Priority': first_record.get('Priority')
        })

        assignee_set = False
        priority_set = False

        # 2. Process Changelog for other events
        for _, row in group.iterrows():
            activity = None
            field = row['ChangedField']
            old_val = str(row['OldValue'])
            new_val = str(row['NewValue'])
            timestamp = row['EventTimestamp']

            # Map changelog entries to activities
            if field == 'status':
                if new_val == 'In Progress' and old_val not in ['Waiting for customer', 'In Progress']:
                    activity = 'Investigation Started'
                elif new_val == 'Waiting for customer':
                    activity = 'Waiting For Customer'
                elif old_val == 'Waiting for customer' and new_val not in ['Resolved', 'Closed']:
                    activity = 'Customer Responded'
                elif new_val == 'Resolved':
                    activity = 'Resolution Proposed'
                    # Also add Incident Resolved at the same time
                    events.append({'IncidentId': incident_id, 'ActivityName': 'Incident Resolved', 'EventTimestamp': timestamp, 'Assignee': row.get('Assignee'), 'AssignmentGroup': row.get('AssignmentGroup'), 'Status': new_val, 'Priority': row.get('Priority')})
                elif new_val == 'Closed':
                    activity = 'Incident Closed'
                elif old_val in ['Resolved', 'Closed'] and new_val not in ['Resolved', 'Closed']:
                    activity = 'Incident Reopened'

            elif field == 'assignee':
                if not assignee_set and new_val != 'nan':
                    activity = 'Incident Assigned'
                    assignee_set = True
                elif assignee_set and new_val != old_val:
                    activity = 'Incident Reassigned'

            elif field == 'priority' and not priority_set:
                activity = 'Incident Prioritized'
                priority_set = True

            elif field == '[Support Team Custom Field]': # Placeholder for your escalation field
                activity = 'Escalated To Specialist Team'
            
            elif field == 'Link' and 'Problem' in new_val:
                 activity = 'Linked To Problem Ticket'

            # Other activities like 'Workaround Provided' and 'Comment Added' are not typically in the changelog
            # and would require different extraction methods (e.g., API calls for comments).

            if activity:
                events.append({
                    'IncidentId': incident_id,
                    'ActivityName': activity,
                    'EventTimestamp': timestamp,
                    'Assignee': row.get('Assignee'),
                    'AssignmentGroup': row.get('AssignmentGroup'),
                    'Status': new_val if field == 'status' else row.get('Status'),
                    'Priority': new_val if field == 'priority' else row.get('Priority')
                })

    # Create final event log DataFrame
    if not events:
        print("Warning: No events were generated. Check your input file and column mappings.")
        return
        
    df_events = pd.DataFrame(events)

    # Add required and recommended attributes
    df_events['SourceSystem'] = 'Jira Service Management'
    df_events['LastDataUpdate'] = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    
    # Merge issue-level details back to get created/resolved dates for all rows
    issue_details = df_raw[['IncidentId', 'CreatedDate', 'ResolutionDate']].drop_duplicates(subset='IncidentId')
    df_final = pd.merge(df_events, issue_details, on='IncidentId', how='left')

    # Calculate cycle time
    df_final['IncidentResolutionCycleTime'] = (df_final['ResolutionDate'] - df_final['CreatedDate']).dt.total_seconds() / 3600.0
    
    # Sort and write to CSV
    df_final = df_final.sort_values(by=['IncidentId', 'EventTimestamp'])
    df_final.to_csv(output_path, index=False)
    print(f"Successfully created event log at '{output_path}' with {len(df_final)} events.")

# --- Script Execution ---
if __name__ == '__main__':
    transform_jira_to_event_log(INPUT_CSV_PATH, OUTPUT_CSV_PATH)

Steps

Prerequisites and Access: Gain read-only access to the on-premise Jira Service Management database. You will need the database server address, port, database name, a username, and a password. Ensure you have a SQL client like DBeaver, SQL Developer, or a similar tool installed.
Understand the Jira Schema: Familiarize yourself with key Jira database tables. The primary tables used in this extraction are jiraissue (for core incident data), changegroup and changeitem (for issue history), jiraaction (for comments), issuelink (for links to other issues), project (to filter by project), and issuetype (to filter for 'Incident' type issues).
Identify Custom Field IDs: Many important attributes like 'Assignment Group' are often custom fields in Jira. You must identify their unique IDs by querying the customfield table (e.g., SELECT id, cfname FROM customfield WHERE cfname LIKE '%Assignment Group%';). Note these IDs for use in the main query.
Connect to the Database: Open your SQL client and establish a connection to the Jira database using the credentials from step 1.
Customize the SQL Query: Copy the complete SQL query provided below. You must replace the placeholder values to match your specific Jira configuration. Pay close attention to [your_project_key], [start_date], [end_date], and any custom field IDs like [custom_field_id_for_assignment_group].
Execute the Query: Run the customized query in your SQL client. Depending on the size of your Jira instance and the selected date range, this may take several minutes to complete.
Review the Results: Once the query finishes, perform a quick review of the output. Check that the columns IncidentId, ActivityName, and EventTimestamp are populated as expected. Ensure a variety of activities appear in the ActivityName column.
Export to CSV: Export the entire result set from your SQL client to a CSV file. Choose UTF-8 encoding to prevent character issues.
Format for ProcessMind: Ensure the CSV file has a header row with the exact column names specified in the query (IncidentId, ActivityName, etc.). Verify that the EventTimestamp column is in a format compatible with ProcessMind, such as YYYY-MM-DD HH:MI:SS.
Upload to ProcessMind: The CSV file is now ready to be uploaded and used to create a new process analysis in ProcessMind.

Configuration

Database Credentials: A read-only database user and password are required to prevent any accidental modification of Jira data.
Project and Issue Type Filtering: The query is designed to be filtered for one or more specific Jira Service Management projects via the p.pkey IN ('[your_project_key]') clause. It is also filtered for the 'Incident' issue type using it.pname = 'Incident'. This is critical for performance and relevance.
Date Range: It is highly recommended to start with a limited date range, such as 3 to 6 months of data, to ensure the query runs efficiently. Adjust the [start_date] and [end_date] placeholders accordingly.
Custom Fields: Attributes like 'Assignment Group' or 'Severity' may be custom fields. The query uses placeholders (e.g., [custom_field_id_for_assignment_group]) which you must replace with the correct numeric IDs from your Jira instance's customfield table.
Jira Version: The database schema can vary slightly between major Jira versions. This query is written for a common schema structure but may require minor adjustments for very old or very new versions of Jira Server or Data Center.
Performance: Executing this query against a large, active Jira instance can consume significant database resources. It is strongly recommended to run it during off-peak hours to minimize impact on Jira users.

a Sample Query sql

WITH Incidents AS (
  SELECT
    i.id AS issue_id,
    p.pkey || '-' || i.issuenum AS IncidentId,
    i.assignee AS assignee_key,
    i.issuestatus AS status_id,
    i.priority AS priority_id,
    i.created AS CreatedDate,
    i.resolutiondate AS ResolutionDate,
    EXTRACT(EPOCH FROM (i.resolutiondate - i.created)) AS IncidentResolutionCycleTime
  FROM jiraissue i
  JOIN project p ON i.project = p.id
  JOIN issuetype it ON i.issuetype = it.id
  WHERE it.pname = 'Incident'
    AND p.pkey IN ('[your_project_key]') -- E.g., 'ITSM', 'HELPDESK'
    AND i.created BETWEEN '[start_date]' AND '[end_date]' -- E.g., '2023-01-01' AND '2023-06-30'
)
-- 1. Incident Created
SELECT
  i.IncidentId,
  'Incident Created' AS ActivityName,
  i.CreatedDate AS EventTimestamp,
  'Jira Service Management' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  au.display_name AS Assignee,
  cfo.customvalue AS AssignmentGroup,
  s.pname AS Status,
  pr.pname AS Priority,
  i.CreatedDate,
  i.ResolutionDate,
  i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN app_user au ON i.assignee_key = au.user_key
LEFT JOIN issuestatus s ON i.status_id = s.id
LEFT JOIN priority pr ON i.priority_id = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group] -- Placeholder for Assignment Group custom field ID
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id

UNION ALL

-- 2. Incident Prioritized (First Time)
SELECT
  i.IncidentId, 'Incident Prioritized' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, T.Priority, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, au_cg.display_name AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status, ci.newstring AS Priority,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN app_user au_cg ON cg.author = au_cg.user_key
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.field = 'Priority'
) T ON i.issue_id = T.issueid AND T.rn = 1

UNION ALL

-- 3. Incident Assigned (First Time)
SELECT
  i.IncidentId, 'Incident Assigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn = 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 4. Investigation Started
SELECT
  i.IncidentId, 'Investigation Started' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Open', 'New') AND ci.newstring = 'In Progress'

UNION ALL

-- 5. Comment Added
SELECT
  i.IncidentId, 'Comment Added' AS ActivityName, ja.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM jiraaction ja
JOIN Incidents i ON ja.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ja.actiontype = 'comment'

UNION ALL

-- 6. Incident Reassigned
SELECT
  i.IncidentId, 'Incident Reassigned' AS ActivityName, T.EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, T.Assignee, T.AssignmentGroup, T.Status, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
JOIN (
    SELECT cg.issueid, cg.created AS EventTimestamp, ci.newstring AS Assignee, cfo.customvalue AS AssignmentGroup, s.pname AS Status,
    ROW_NUMBER() OVER(PARTITION BY cg.issueid ORDER BY cg.created ASC) as rn
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    JOIN Incidents inc_filter ON cg.issueid = inc_filter.issue_id
    LEFT JOIN jiraissue ji_state ON cg.issueid = ji_state.id
    LEFT JOIN issuestatus s ON ji_state.issuestatus = s.id
    LEFT JOIN customfieldvalue cfv_group ON cg.issueid = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
    LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
    WHERE ci.fieldtype = 'jira' AND ci.field = 'assignee' AND ci.newvalue IS NOT NULL
) T ON i.issue_id = T.issueid AND T.rn > 1
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN priority pr ON ji.priority = pr.id

UNION ALL

-- 7. Escalated To Specialist Team
SELECT
  i.IncidentId, 'Escalated To Specialist Team' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, ci.newstring, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
JOIN customfield cf ON cf.cfname = '[Support Team Custom Field Name]' -- Placeholder for custom field name, e.g., 'Support Team'
JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
WHERE ci.field = cf.id

UNION ALL

-- 8. Waiting For Customer
SELECT
  i.IncidentId, 'Waiting For Customer' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Waiting for Customer'

UNION ALL

-- 9. Customer Responded
SELECT
  i.IncidentId, 'Customer Responded' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring = 'Waiting for Customer'

UNION ALL

-- 10. Workaround Provided
SELECT
  i.IncidentId, 'Workaround Provided' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Workaround Provided' -- Assumes this status exists

UNION ALL

-- 11. Resolution Proposed & 14. Incident Resolved
SELECT
  i.IncidentId, 'Resolution Proposed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Resolved'

UNION ALL

-- Also capture Incident Resolved from the resolutiondate field for cases where history might be missed.
SELECT
  i.IncidentId, 'Incident Resolved' AS ActivityName, i.ResolutionDate AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM Incidents i
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE i.ResolutionDate IS NOT NULL

UNION ALL

-- 12. Linked To Problem Ticket
SELECT
  i.IncidentId, 'Linked To Problem Ticket' AS ActivityName, il.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, s.pname, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM issuelink il
JOIN Incidents i ON il.source = i.issue_id
JOIN jiraissue linked_issue ON il.destination = linked_issue.id
JOIN issuetype linked_issuetype ON linked_issue.issuetype = linked_issuetype.id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN issuestatus s ON ji.issuestatus = s.id
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE linked_issuetype.pname = 'Problem'

UNION ALL

-- 13. Incident Reopened
SELECT
  i.IncidentId, 'Incident Reopened' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.oldstring IN ('Resolved', 'Closed') AND ci.newstring NOT IN ('Resolved', 'Closed')

UNION ALL

-- 15. Incident Closed
SELECT
  i.IncidentId, 'Incident Closed' AS ActivityName, cg.created AS EventTimestamp, 'Jira Service Management', CURRENT_TIMESTAMP, au.display_name, cfo.customvalue, ci.newstring, pr.pname, i.CreatedDate, i.ResolutionDate, i.IncidentResolutionCycleTime
FROM changegroup cg
JOIN changeitem ci ON cg.id = ci.groupid
JOIN Incidents i ON cg.issueid = i.issue_id
LEFT JOIN jiraissue ji ON i.issue_id = ji.id
LEFT JOIN app_user au ON ji.assignee = au.user_key
LEFT JOIN priority pr ON ji.priority = pr.id
LEFT JOIN customfieldvalue cfv_group ON i.issue_id = cfv_group.issue AND cfv_group.customfield = [custom_field_id_for_assignment_group]
LEFT JOIN customfieldoption cfo ON cfv_group.stringvalue = cfo.id
WHERE ci.field = 'status' AND ci.newstring = 'Closed'

Steps

Set Up Python Environment: Ensure you have Python 3.6 or newer installed on your system. Install the necessary libraries using pip: pip install requests pandas python-dateutil.
Generate Jira API Token: Log in to your Jira account. Go to your profile settings, select 'Security', then 'Create and manage API tokens'. Create a new token and copy it securely. This token will be used for authentication instead of a password.
Identify Custom Field IDs: Many Jira attributes like 'Assignment Group' or 'Severity' are custom fields. You need to find their internal IDs. Navigate to Jira Settings > Issues > Custom fields. Find the relevant field and click the '...' menu to select 'View'. The ID will be in the URL (e.g., customFieldId=10021). Note these down.
Configure the Python Script: Open the provided Python script in a text editor. Update the placeholder variables in the ## CONFIGURATION ## section with your Jira site URL, your email, the API token you generated, and the custom field IDs you identified.
Define the JQL Query: Modify the JQL_QUERY variable in the script. This Jira Query Language (JQL) query defines the scope of incidents to be extracted. Start with a specific project and a limited date range to test, for example: project = 'ITSM' AND issuetype = 'Incident' AND created >= '-90d'.
Run the Extraction Script: Execute the script from your command line using python your_script_name.py. The script will connect to the Jira API, fetch the incident data, process the history for each ticket, and generate events.
Monitor Script Progress: The script is designed to print progress to the console, showing how many issues have been processed. For large datasets, this may take a considerable amount of time due to API rate limits and the volume of data.
Review the Output File: Once the script completes, it will generate a file named jira_incident_event_log.csv in the same directory. This file contains the extracted event log.
Data Transformation and Formatting: Open the CSV file in a spreadsheet program to review. The script automatically calculates IncidentResolutionCycleTime. Ensure the date format for EventTimestamp is consistent and compatible with ProcessMind requirements (e.g., YYYY-MM-DDTHH:MI:SSZ).
Upload to ProcessMind: The generated CSV file is now ready to be uploaded to ProcessMind. Map the columns from the CSV file to the corresponding attributes in ProcessMind (IncidentId to Case ID, ActivityName to Activity, EventTimestamp to Timestamp).

Configuration

Jira URL: The base URL of your Jira instance (e.g., https://your-company.atlassian.net).
Jira Credentials: An email address and a Jira API token are required for authentication. Do not use your password directly in the script.
JQL Query: The JQL query is the most critical setting for defining the data scope. It is highly recommended to filter by issuetype = 'Incident' and a specific project. Use a date range filter on the created field (e.g., created >= '-180d') to manage the data volume. A range of 3 to 6 months is typical for an initial analysis.
Custom Field IDs: The script requires the specific IDs for custom fields used in your Jira instance, such as ASSIGNMENT_GROUP_FIELD_ID. These must be configured correctly for the corresponding attributes to be populated.
Status Names: The script infers activities based on status transitions. You must update the status names in the script (e.g., 'In Progress', 'Waiting for customer', 'Resolved') to match the exact names used in your project's workflow.
Pagination Settings: The maxResults parameter in the API call controls how many issues are fetched per request. The script handles pagination automatically, but a smaller value may be gentler on the API if you encounter rate limiting.

a Sample Query python

import requests
import pandas as pd
import os
from datetime import datetime, timezone
from dateutil.parser import parse

class=class="hl-string">"hl-comment">## CONFIGURATION ##
class=class="hl-string">"hl-comment"># Your Jira instance URL
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
class=class="hl-string">"hl-comment"># Your email address used for Jira login
JIRA_EMAIL = class="hl-string">"[your-email@company.com]"
class=class="hl-string">"hl-comment"># Your Jira API token. Store this securely, for example as an environment variable.
API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"[Your_Jira_API_Token]")

class=class="hl-string">"hl-comment"># JQL query to fetch incidents. It is recommended to limit the date range.
JQL_QUERY = class="hl-string">"issuetype = Incident AND project = '[YOUR_PROJECT_KEY]' AND created >= '-180d'"

class=class="hl-string">"hl-comment"># Custom field IDs for recommended attributes. Find these in your Jira settings.
class=class="hl-string">"hl-comment"># Example: class="hl-string">'customfield_10021'
ASSIGNMENT_GROUP_FIELD_ID = class="hl-string">"[customfield_id_for_assignment_group]"

class=class="hl-string">"hl-comment"># Status names as defined in your Jira workflow
STATUS_IN_PROGRESS = class="hl-string">'In Progress'
STATUS_WAITING_FOR_CUSTOMER = class="hl-string">'Waiting for customer'
STATUS_RESOLVED = class="hl-string">'Resolved'
STATUS_CLOSED = class="hl-string">'Closed'

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

def get_field_value_from_changelog(item):
    class=class="hl-string">"hl-comment"># Helper to get the actual value, which can be in different keys
    return item.get(class="hl-string">'toString') or item.get(class="hl-string">'to') or class="hl-string">''

def get_field_from_changelog(item):
    return item.get(class="hl-string">'fromString') or item.get(class="hl-string">'from') or class="hl-string">''

def calculate_cycle_time(start_str, end_str):
    if not start_str or not end_str:
        return None
    try:
        start_dt = parse(start_str)
        end_dt = parse(end_str)
        duration_seconds = (end_dt - start_dt).total_seconds()
        return round(duration_seconds / 3600, 2) class=class="hl-string">"hl-comment"># Return cycle time in hours
    except (ValueError, TypeError):
        return None

def fetch_jira_issues(jql):
    class="hl-string">"""Fetches issues from Jira API, handling pagination."""
    auth = (JIRA_EMAIL, API_TOKEN)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    issues = []
    start_at = 0
    max_results = 50

    while True:
        api_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_url, headers=headers, params=params, auth=auth)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            data = response.json()
            issues.extend(data.get(class="hl-string">'issues', []))

            total = data.get(class="hl-string">'total', 0)
            start_at += len(data.get(class="hl-string">'issues', []))
            print(fclass="hl-string">"Fetched {start_at} of {total} issues...")

            if start_at >= total:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from Jira: {e}")
            if e.response is not None:
                print(fclass="hl-string">"Response content: {e.response.text}")
            break

    return issues

def create_event_log(issues):
    class="hl-string">"""Processes issues and their changelogs to create a structured event log."""
    event_log = []
    last_data_update = datetime.now(timezone.utc).isoformat()

    for issue in issues:
        incident_id = issue[class="hl-string">'key']
        fields = issue[class="hl-string">'fields']
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        created_date = fields.get(class="hl-string">'created')
        resolution_date = fields.get(class="hl-string">'resolutiondate')
        cycle_time = calculate_cycle_time(created_date, resolution_date)

        class=class="hl-string">"hl-comment"># Track current state for attributes
        current_assignee = fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None
        current_status = fields.get(class="hl-string">'status', {}).get(class="hl-string">'name')
        current_priority = fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name') if fields.get(class="hl-string">'priority') else None
        current_assignment_group = fields.get(ASSIGNMENT_GROUP_FIELD_ID)

        class=class="hl-string">"hl-comment"># Base attributes for every event of this case
        base_event = {
            class="hl-string">'IncidentId': incident_id,
            class="hl-string">'SourceSystem': class="hl-string">'Jira Service Management',
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'CreatedDate': created_date,
            class="hl-string">'ResolutionDate': resolution_date,
            class="hl-string">'IncidentResolutionCycleTime': cycle_time
        }

        class=class="hl-string">"hl-comment"># 1. Incident Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Incident Created',
            class="hl-string">'EventTimestamp': created_date,
            class="hl-string">'Assignee': current_assignee,
            class="hl-string">'AssignmentGroup': current_assignment_group,
            class="hl-string">'Status': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'Priority': current_priority
        })

        class=class="hl-string">"hl-comment"># 2. Comments Added
        if fields.get(class="hl-string">'comment', {}).get(class="hl-string">'comments'):
            for comment in fields[class="hl-string">'comment'][class="hl-string">'comments']:
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': class="hl-string">'Comment Added',
                    class="hl-string">'EventTimestamp': comment[class="hl-string">'created'],
                    class="hl-string">'Assignee': current_assignee, class=class="hl-string">"hl-comment"># Note: Assignee at time of comment is not easily available
                    class="hl-string">'AssignmentGroup': current_assignment_group,
                    class="hl-string">'Status': current_status,
                    class="hl-string">'Priority': current_priority
                })

        class=class="hl-string">"hl-comment"># 3. Linked To Problem Ticket
        if fields.get(class="hl-string">'issuelinks'):
            for link in fields[class="hl-string">'issuelinks']:
                link_type = link.get(class="hl-string">'type', {}).get(class="hl-string">'name')
                if class="hl-string">'inwardIssue' in link and link.get(class="hl-string">'inwardIssue', {}).get(class="hl-string">'fields', {}).get(class="hl-string">'issuetype', {}).get(class="hl-string">'name') == class="hl-string">'Problem':
                     event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': class="hl-string">'Linked To Problem Ticket',
                        class="hl-string">'EventTimestamp': created_date, class=class="hl-string">"hl-comment"># Approximation: link creation time is not readily available
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

        class=class="hl-string">"hl-comment"># Process changelog for state changes
        first_assignment = True
        first_prioritization = True

        for history in sorted(changelog, key=lambda x: x[class="hl-string">'created']):
            event_timestamp = history[class="hl-string">'created']
            author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

            for item in history[class="hl-string">'items']:
                field = item.get(class="hl-string">'field', class="hl-string">'').lower()
                activity = None

                class=class="hl-string">"hl-comment"># Track attribute changes over time
                if field == class="hl-string">'assignee':
                    current_assignee = get_field_value_from_changelog(item)
                    if first_assignment and get_field_from_changelog(item) is None:
                        activity = class="hl-string">'Incident Assigned'
                        first_assignment = False
                    elif not first_assignment:
                        activity = class="hl-string">'Incident Reassigned'
                elif field == class="hl-string">'priority' and first_prioritization:
                    current_priority = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Incident Prioritized'
                    first_prioritization = False
                elif field == class="hl-string">'status':
                    from_status = item.get(class="hl-string">'fromString')
                    to_status = item.get(class="hl-string">'toString')
                    current_status = to_status
                    if to_status == STATUS_IN_PROGRESS:
                        activity = class="hl-string">'Investigation Started'
                    elif to_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Waiting For Customer'
                    elif from_status == STATUS_WAITING_FOR_CUSTOMER:
                        activity = class="hl-string">'Customer Responded'
                    elif to_status == STATUS_RESOLVED:
                        class=class="hl-string">"hl-comment"># This can represent both Proposed and Resolved
                        event_log.append({
                            **base_event,
                            class="hl-string">'ActivityName': class="hl-string">'Resolution Proposed',
                            class="hl-string">'EventTimestamp': event_timestamp,
                            class="hl-string">'Assignee': current_assignee,
                            class="hl-string">'AssignmentGroup': current_assignment_group,
                            class="hl-string">'Status': to_status,
                            class="hl-string">'Priority': current_priority
                        })
                        activity = class="hl-string">'Incident Resolved'
                    elif to_status == STATUS_CLOSED:
                        activity = class="hl-string">'Incident Closed'
                    elif from_status in [STATUS_RESOLVED, STATUS_CLOSED] and to_status not in [STATUS_RESOLVED, STATUS_CLOSED]:
                         activity = class="hl-string">'Incident Reopened'
                elif item.get(class="hl-string">'fieldId') == ASSIGNMENT_GROUP_FIELD_ID:
                    current_assignment_group = get_field_value_from_changelog(item)
                    activity = class="hl-string">'Escalated To Specialist Team'
                elif field == class="hl-string">'resolution' and item.get(class="hl-string">'toString') == class="hl-string">'Workaround provided':
                    class=class="hl-string">"hl-comment"># This is one way to capture class="hl-string">'Workaround Provided', highly dependent on configuration
                    activity = class="hl-string">'Workaround Provided'

                if activity:
                    event_log.append({
                        **base_event,
                        class="hl-string">'ActivityName': activity,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'Assignee': current_assignee,
                        class="hl-string">'AssignmentGroup': current_assignment_group,
                        class="hl-string">'Status': current_status,
                        class="hl-string">'Priority': current_priority
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira incident data extraction...")
    issues_data = fetch_jira_issues(JQL_QUERY)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues to create event log...")
        event_log_data = create_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        class=class="hl-string">"hl-comment"># Sort by case and timestamp for a logical event log order
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        
        output_filename = class="hl-string">'jira_incident_event_log.csv'
        df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nExtraction complete. Event log saved to '{output_filename}'.")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

Steps

Prerequisite Check: This method requires a Jira Marketplace App like 'Better Excel Exporter' or 'Exporter for Jira', as the standard built-in CSV export does not include the detailed issue history (changelog) required to reconstruct the process timeline. Verify that such an app is installed and you have permissions to use it.
Navigate to Advanced Issue Search: Log into your Jira Service Management instance. In the top navigation bar, select 'Filters' and then 'Advanced issue search'. This will open the Issue Navigator with the JQL query editor.
Execute JQL Query: In the JQL query bar, enter the provided JQL query to select all incident tickets within a specified date range. This will form the basis of your raw data export. A typical query would be issuetype = Incident AND project = "[Your JSM Project Key]" AND created >= "-180d".
Configure Export Columns: Locate the export option, which may be labeled 'Export' or be under an app-specific menu. Configure the export to create a CSV file. It is critical to include the following fields: Issue Key, Created, Resolved, Status, Priority, Assignee, and most importantly, the full Changelog or History. Exporter apps often allow you to export each changelog item as a separate row, which is the ideal format for transformation.
Export the Raw Data: Execute the export and download the resulting CSV file. This file will contain the raw, untransformed data, likely with one row per issue change rather than one row per issue.
Prepare the Transformation Environment: The provided Python script is required to transform the raw export into a valid event log. Ensure you have Python and the pandas library installed on your system. You can install pandas by running pip install pandas in your terminal.
Run the Transformation Script: Save the provided Python script to a file (e.g., transform_jira_log.py). Place the exported CSV file in the same directory. Modify the script to specify the correct input and output filenames.
Execute the Script: Run the script from your terminal using the command: python transform_jira_log.py. The script will process the raw data and generate a new CSV file named jira_incident_event_log.csv, formatted correctly for process mining.
Review and Upload: Open the final jira_incident_event_log.csv file to validate its contents. Once confirmed, this event log is ready to be uploaded to your process mining tool.

Configuration

JQL Query: The JQL (Jira Query Language) query is the primary filter for selecting data. Key filters include:
- issuetype = Incident: Ensures you only extract incident tickets.
- project = "[Your JSM Project Key]": Restricts the data to a specific service desk project. Replace the placeholder with your project's key (e.g., 'ITSUP').
- created >= "-180d": Sets the date range for the extraction. A period of 3-6 months ('-90d' to '-180d') is recommended to balance data volume and insight.
Export App Configuration: The Marketplace exporter app must be configured to output the changelog. The ideal output format is one row per change, with columns indicating the Issue Key, the field that was changed, the old value, the new value, and the timestamp of the change.
Required Fields for Export: Ensure the export includes at least Issue Key, Created, Resolved, Creator, Priority, Status, Assignee, [Assignment Group Custom Field], [Support Team Custom Field], and the full Changelog history (timestamp, author, field, from string, to string).
Prerequisites: This method requires a Jira Service Management license, user permissions to access the Issue Navigator and run JQL queries, and an installed Jira Marketplace app capable of exporting detailed issue changelogs.

a Sample Query config

import pandas as pd
import numpy as np
from datetime import datetime

# --- Configuration ---
# Specify the path to your raw CSV file exported from Jira
# This file should have one row per changelog item.
INPUT_CSV_PATH = '[Your-Jira-Export-File].csv'
# Specify the desired name for the final event log file
OUTPUT_CSV_PATH = 'jira_incident_event_log.csv'

# --- Main Transformation Logic ---
def transform_jira_to_event_log(input_path, output_path):
    """Transforms a detailed Jira changelog export into a process mining event log."""
    try:
        # Load the raw data, assuming common column names from Jira exporters.
        # Adjust column names here to match your specific export file.
        # 'Issue Key' -> Incident ID
        # 'Date' -> Timestamp of the change
        # 'Field' -> The field that was changed (e.g., 'status', 'assignee')
        # 'Original value' -> Old value
        # 'New value' -> New value
        # You must also include columns for 'Created', 'Resolved', 'Priority', etc., at the issue level.
        df_raw = pd.read_csv(input_path)
    except FileNotFoundError:
        print(f"Error: Input file not found at '{input_path}'. Please check the path.")
        return

    # Standardize column names for easier processing
    # Replace these with the actual column names from your export
    column_map = {
        'Issue key': 'IncidentId',
        'History Date': 'EventTimestamp',
        'History Author': 'Author',
        'Field': 'ChangedField',
        'From String': 'OldValue',
        'To String': 'NewValue',
        'Created': 'CreatedDate',
        'Resolved': 'ResolutionDate',
        'Priority': 'Priority',
        'Status': 'Status',
        'Assignee': 'Assignee',
        # Add mappings for your custom fields if necessary
        # '[Your Assignment Group Field]': 'AssignmentGroup'
    }
    df_raw.rename(columns=column_map, inplace=True)

    # Ensure timestamp columns are in datetime format
    df_raw['EventTimestamp'] = pd.to_datetime(df_raw['EventTimestamp'], errors='coerce')
    df_raw['CreatedDate'] = pd.to_datetime(df_raw['CreatedDate'], errors='coerce')
    df_raw['ResolutionDate'] = pd.to_datetime(df_raw['ResolutionDate'], errors='coerce')

    events = []
    # Group by incident to process each ticket's lifecycle
    for incident_id, group in df_raw.groupby('IncidentId'):
        # Sort changes chronologically
        group = group.sort_values(by='EventTimestamp').reset_index()

        # Get issue-level attributes from the first record
        first_record = group.iloc[0]
        created_date = first_record['CreatedDate']
        resolved_date = first_record['ResolutionDate']

        # 1. Incident Created Event
        events.append({
            'IncidentId': incident_id,
            'ActivityName': 'Incident Created',
            'EventTimestamp': created_date,
            'Assignee': first_record.get('Assignee'),
            'AssignmentGroup': first_record.get('AssignmentGroup'),
            'Status': first_record.get('Status'),
            'Priority': first_record.get('Priority')
        })

        assignee_set = False
        priority_set = False

        # 2. Process Changelog for other events
        for _, row in group.iterrows():
            activity = None
            field = row['ChangedField']
            old_val = str(row['OldValue'])
            new_val = str(row['NewValue'])
            timestamp = row['EventTimestamp']

            # Map changelog entries to activities
            if field == 'status':
                if new_val == 'In Progress' and old_val not in ['Waiting for customer', 'In Progress']:
                    activity = 'Investigation Started'
                elif new_val == 'Waiting for customer':
                    activity = 'Waiting For Customer'
                elif old_val == 'Waiting for customer' and new_val not in ['Resolved', 'Closed']:
                    activity = 'Customer Responded'
                elif new_val == 'Resolved':
                    activity = 'Resolution Proposed'
                    # Also add Incident Resolved at the same time
                    events.append({'IncidentId': incident_id, 'ActivityName': 'Incident Resolved', 'EventTimestamp': timestamp, 'Assignee': row.get('Assignee'), 'AssignmentGroup': row.get('AssignmentGroup'), 'Status': new_val, 'Priority': row.get('Priority')})
                elif new_val == 'Closed':
                    activity = 'Incident Closed'
                elif old_val in ['Resolved', 'Closed'] and new_val not in ['Resolved', 'Closed']:
                    activity = 'Incident Reopened'

            elif field == 'assignee':
                if not assignee_set and new_val != 'nan':
                    activity = 'Incident Assigned'
                    assignee_set = True
                elif assignee_set and new_val != old_val:
                    activity = 'Incident Reassigned'

            elif field == 'priority' and not priority_set:
                activity = 'Incident Prioritized'
                priority_set = True

            elif field == '[Support Team Custom Field]': # Placeholder for your escalation field
                activity = 'Escalated To Specialist Team'
            
            elif field == 'Link' and 'Problem' in new_val:
                 activity = 'Linked To Problem Ticket'

            # Other activities like 'Workaround Provided' and 'Comment Added' are not typically in the changelog
            # and would require different extraction methods (e.g., API calls for comments).

            if activity:
                events.append({
                    'IncidentId': incident_id,
                    'ActivityName': activity,
                    'EventTimestamp': timestamp,
                    'Assignee': row.get('Assignee'),
                    'AssignmentGroup': row.get('AssignmentGroup'),
                    'Status': new_val if field == 'status' else row.get('Status'),
                    'Priority': new_val if field == 'priority' else row.get('Priority')
                })

    # Create final event log DataFrame
    if not events:
        print("Warning: No events were generated. Check your input file and column mappings.")
        return
        
    df_events = pd.DataFrame(events)

    # Add required and recommended attributes
    df_events['SourceSystem'] = 'Jira Service Management'
    df_events['LastDataUpdate'] = datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    
    # Merge issue-level details back to get created/resolved dates for all rows
    issue_details = df_raw[['IncidentId', 'CreatedDate', 'ResolutionDate']].drop_duplicates(subset='IncidentId')
    df_final = pd.merge(df_events, issue_details, on='IncidentId', how='left')

    # Calculate cycle time
    df_final['IncidentResolutionCycleTime'] = (df_final['ResolutionDate'] - df_final['CreatedDate']).dt.total_seconds() / 3600.0
    
    # Sort and write to CSV
    df_final = df_final.sort_values(by=['IncidentId', 'EventTimestamp'])
    df_final.to_csv(output_path, index=False)
    print(f"Successfully created event log at '{output_path}' with {len(df_final)} events.")

# --- Script Execution ---
if __name__ == '__main__':
    transform_jira_to_event_log(INPUT_CSV_PATH, OUTPUT_CSV_PATH)

Data Template: Incident Management

Your Incident Management Data Template

Incident Management Attributes

Incident Management Activities

Extraction Guides

Jira Service Management Issue Navigator CSV Export

Steps

Configuration

a Sample Query config

Direct SQL Query on Jira's On-Premise Database

Steps

Configuration

a Sample Query sql

Python Script using Jira REST API for Data Extraction

Steps

Configuration

a Sample Query python

Jira Automation Rule with Webhook for Live Extraction

Steps

Configuration

a Sample Query config

Ready to Get Started?

Optimize Incident Management, Resolve Incidents Faster Now