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

Your Problem Management Data Template

Jira Service Management

Problem Management Attributes (21) Problem Management Activities (14) Extraction Guides (2)

Your Problem Management Data Template

This template serves as a comprehensive roadmap for analyzing your IT service management workflows by identifying the essential data points and process milestones within Jira Service Management. It provides a structured overview of the attributes and activities necessary to gain full visibility into how your team handles underlying issues and root cause analysis. Use these guidelines to streamline your data collection and ensure your process mining initiatives yield actionable insights.

Recommended attributes for deep analysis
Process milestones to capture in your event log
Technical guidance for data extraction

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

Download Template

Problem Management Attributes

These are the recommended data fields to include in your event log for a comprehensive analysis of your problem management lifecycle.

5 Required 5 Recommended 11 Optional

	Name	Description
	Activity ActivityName	The specific action or status change that occurred for the problem record.
Description This attribute captures the name of the event or state transition occurring within the problem management lifecycle. Examples include 'Problem Logged', 'Status Changed to Investigating', or 'Root Cause Identified'. It is essential for mapping the process flow and identifying the sequence of steps taken to resolve a problem. In process mining, these activities form the nodes of the process map. Why it matters Defines the steps in the process map and allows for the analysis of process variants. Where to get Jira Changelog (History) or Issue Status transitions Examples Problem Record CreatedInvestigation StartedRoot Cause IdentifiedWorkaround UpdatedProblem Record Closed
	Last Data Update LastDataUpdate	The timestamp when the data was extracted or last refreshed.
Description Indicates when the dataset was last synchronized with the live Jira Service Management environment. This ensures analysts understand the freshness of the data. It is used to validate that the analysis reflects the most current state of the process and to identify potential data latency issues. Why it matters Ensures data freshness and helps trust the analysis results. Where to get ETL Timestamp Examples 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Problem Record ProblemKey	The unique identifier assigned to the problem record in Jira Service Management.
Description This attribute serves as the central case identifier for the process mining analysis. It represents the unique key (e.g., PM-1001) generated by Jira Service Management when a new problem record is created. It is used to group all related activities, status changes, and updates into a single end-to-end process instance. Analyzing this attribute allows for the visualization of the complete lifecycle of a problem from initial detection through investigation to final closure. Why it matters It is the fundamental key required to reconstruct the process flow and track specific problem records. Where to get Issue table, field 'Key' or 'Issue Key' Examples PM-1023PM-4099PRB-3321PM-5001
	Source System SourceSystem	The name of the system where the data originated.
Description Identifies the software system from which the process data was extracted. In this context, the value is consistently 'Jira Service Management'. This attribute is particularly useful in multi-system environments to distinguish data sources, though for this specific view, it serves primarily as a static identifier for data lineage. Why it matters Provides context for data origin, especially when merging with other IT Service Management data. Where to get Hardcoded or System Configuration Examples Jira Service ManagementJira CloudJSM-Prod
	Timestamp EventTimestamp	The exact date and time when the activity occurred.
Description This attribute records the precise moment an activity took place. It is used to sequence events chronologically and calculate durations between steps. Accurate timestamps are critical for calculating cycle times, such as the time from 'Problem Logged' to 'Root Cause Identified', and for analyzing throughput over time. Why it matters Enables the calculation of all time-based KPIs and the correct ordering of events. Where to get Jira Changelog created date or Issue created date Examples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Assigned Support Group SupportGroup	The technical team or group currently assigned to investigate the problem.
Description Identifies the specific team responsible for the problem record at the time of the event. In Jira Service Management, this is often mapped to 'Component' or a custom field like 'Support Group'. This attribute is vital for the 'Support Group Handover Bottlenecks' dashboard, allowing analysts to visualize how problems move between teams and where they sit the longest. Why it matters Essential for organizational mining and identifying cross-team friction. Where to get Issue field 'Component' or custom field 'Support Group' Examples Database AdministrationNetwork OpsApplication Support Level 2
	Priority Priority	The criticality level assigned to the problem record.
Description Indicates the urgency and impact of the problem, typically ranging from 'Low' to 'Critical'. This field is used to segment analysis and ensure that high-priority problems are being resolved within SLA targets. Analyzing this attribute helps in the 'SLA Compliance and Target Trends' dashboard to verify if critical business risks are prioritized correctly. Why it matters Allows segmentation of process performance by business criticality. Where to get Issue field 'Priority' Examples HighestHighMediumLow
	Problem Summary ProblemSummary	The short text description or title of the problem record.
Description Contains the headline summary of the problem record. While primarily text-based, it provides context for analysts reviewing individual cases within the process mining tool. It allows for keyword search and qualitative analysis of the types of problems being logged. Why it matters Provides human-readable context for the case identifier. Where to get Issue field 'Summary' Examples Database connection timeout in region EUEmail service latency spikeOrder processing queue stuck
	Root Cause Category RootCauseCategory	The classification of the underlying cause of the problem.
Description Categorizes the technical or process failure that caused the problem, such as 'Software Bug', 'Human Error', or 'Hardware Failure'. This is often a custom field in Jira Service Management. This attribute supports the 'Root Cause Category Distribution' dashboard, enabling strategic decisions on where to invest in infrastructure or training to prevent recurrence. Why it matters Key for identifying systemic issues and guiding preventative measures. Where to get Custom field 'Root Cause' or 'Root Cause Category' Examples Software BugConfiguration ErrorCapacity IssueVendor Issue
	User UserKey	The unique identifier or name of the user who performed the activity.
Description Captures the identity of the person or system account responsible for executing the specific activity. This could be the 'Assignee' updating the record or the 'Author' of a status change. This data is used to analyze resource utilization, identify handover bottlenecks between users, and ensure accountability within the problem management process. Why it matters Critical for analyzing handovers, segregation of duties, and resource workload. Where to get Jira 'author' field in changelog or 'assignee' field on issue Examples j.smithsystem_automationm.doe
	Creation Date CreatedDate	The date the problem record was created.
Description The timestamp when the problem was first logged in the system. While the event timestamp handles activity timing, this specific attribute is often used for high-level filtering (e.g., 'Show me all problems created in Q1'). It serves as the anchor point for aging analysis. Why it matters Anchor date for aging and intake volume analysis. Where to get Issue field 'Created' Examples 2023-01-012023-06-15
	Detection Source DetectionSource	How the problem was identified (e.g., Proactive, Reactive).
Description Indicates the origin of the problem identification. Common values include 'Proactive Monitoring', 'Service Desk Incident', or 'Vendor Notification'. This attribute is used in the 'Proactive vs Reactive Identification' dashboard to measure the maturity of the problem management process. Why it matters Measures process maturity and the effectiveness of monitoring systems. Where to get Custom field 'Source' or 'Detection Source' Examples Proactive MonitoringIncident EscalationSupplier Notification
	Investigation Duration InvestigationDuration	Time taken from problem logging to root cause identification.
Description Calculates the duration between the creation of the problem record and the timestamp of the 'Root Cause Identified' activity. This is the primary metric for the 'Investigation Cycle Time Analysis' dashboard. It helps managers identify complex problems that stalled the team or lack of resources in the diagnosis phase. Why it matters Primary metric for the efficiency of the root cause analysis phase. Where to get Calculated from event timestamps Examples 48 hours5 days30 minutes
	Is Reopened IsReopened	Flag indicating if the problem was reopened after closure.
Description A boolean flag that is set to true if the problem record transitioned from a closed state back to an open state. This supports the 'Problem Reopened Rate Analysis'. High rates of reopening indicate quality issues with the permanent fixes or insufficient verification procedures. Why it matters Quality indicator for the effectiveness of fixes. Where to get Derived from status transitions Examples truefalse
	Linked Change Request LinkedChangeRequest	The identifier of the change request linked to this problem.
Description Stores the ID of the Change Request (RFC) created to implement the permanent fix. This link is vital for the 'Change Request Initiation Lag' dashboard. It connects the Problem Management process to Change Management, allowing for cross-process analysis. Why it matters Connects investigation to remediation in the Change Management process. Where to get Issue links where type is 'is fixed by' or similar Examples CR-404CHG-1099CR-5512
	Linked Incident Count LinkedIncidentCount	The number of incidents linked to this problem record.
Description A count of incident tickets that are associated with the problem record. This attribute quantifies the impact of the problem on the user base. It is used in the 'Incident to Problem Linkage Depth' KPI to prioritize problems that are generating the highest volume of support tickets. Why it matters Quantifies business impact based on incident volume. Where to get Count of links in 'issuelinks' table where type is 'Problem/Incident' Examples 011550
	PIR Conducted ReviewStatus	Indicates if a Post Implementation Review (PIR) was performed.
Description Tracks whether the 'Post Implementation Review' activity or flag is present on the case. This is essential for the 'Post Implementation Review Compliance' dashboard. It ensures that the organization is adhering to governance requirements for continuous improvement. Why it matters Compliance metric for organizational learning. Where to get Custom field 'PIR Status' or existence of 'PIR' activity Examples CompletedPendingNot Required
	Reporter ReporterName	The user who originally logged the problem record.
Description Identifies the individual who created the problem record. This is distinct from the assignee. Analyzing reporters helps understand where problems are being detected (e.g., Service Desk Agents vs. System Admins). This adds context to the 'Proactive vs Reactive' analysis. Why it matters Identifies the source of problem intake. Where to get Issue field 'Reporter' Examples monitoring_servicehelpdesk_leadnetwork_admin
	Resolution Code ResolutionCode	The code indicating how the problem was resolved.
Description Specifies the final outcome of the problem record, such as 'Fixed', 'Won't Fix', 'Duplicate', or 'Cannot Reproduce'. This is used to filter successfully resolved problems from those closed for administrative reasons, ensuring that KPI calculations like 'Mean Time to Root Cause' are accurate. Why it matters Distinguishes between effective fixes and administrative closures. Where to get Issue field 'Resolution' Examples DoneWon't DoDuplicateCannot Reproduce
	SLA Breach Status SlaBreachStatus	Indicates if the problem record has breached its service level agreement.
Description A boolean or status field indicating whether the resolution time has exceeded the agreed target. This helps in the 'SLA Compliance and Target Trends' dashboard. It highlights cases that expose the organization to compliance risks or penalties. Why it matters Critical for compliance and performance monitoring. Where to get Jira Service Management SLA field logic Examples MetBreachedPaused
	Workaround Available WorkaroundDetails	Indicates if a workaround has been documented for the problem.
Description Captures whether a temporary workaround text exists or has been published. This allows the organization to track the 'Workaround Publication Speed'. Analysis of this field helps determine how quickly the team can restore service stability even before a permanent fix is found. Why it matters Key for measuring the speed of interim relief provided to the business. Where to get Custom field 'Workaround' Examples Restart the serviceClear browser cacheNone provided

Required Recommended Optional

Problem Management Activities

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

8 Recommended 6 Optional

	Activity	Description
	Assigned to Support Group	The assignment of the problem record to a specific technical team or support group. This is tracked via changes to the 'Support Group' custom field or the 'Assignee' field if groups are not used.
Why it matters Critical for analyzing handovers and bottlenecks between teams. High transfer rates can indicate routing inefficiencies. Where to get Jira Issue History: Field 'Support Group' or 'Assignee' changed Capture Logged when the assignment field changes Event type explicit
	Incident Linked to Problem	The action of linking a related Incident ticket to the Problem record. This is captured in the issue links table or history.
Why it matters Determines the impact and scope of the problem. Essential for the 'Incident to Problem Linkage Depth' KPI and prioritizing based on business impact. Where to get Jira Issue Links: Link created with type 'causes' or 'relates to' Capture Logged when an issue link is created Event type explicit
	Investigation Started	The transition of the problem status to an active investigation state (e.g., 'Under Investigation' or 'In Progress'). This marks the beginning of the active work phase.
Why it matters Starts the clock for the investigation cycle time. Helps distinguish between backlog wait time and actual active analysis. Where to get Jira Issue History: Status changed to 'Under Investigation' or 'In Progress' Capture Compare status field updates Event type inferred
	Problem Record Closed	The final termination of the problem lifecycle. Captured explicitly when the status changes to 'Closed'.
Why it matters The definitive end of the process instance. Necessary for calculating total cycle time and closure rates. Where to get Jira Issue History: Status changed to 'Closed' Capture Logged when status transitions to Closed Event type explicit
	Problem Record Created	The initial event where the Problem ticket is created in the system. This is explicitly captured in the issue history as the creation timestamp.
Why it matters Marks the start of the problem management lifecycle and allows for volume analysis. Essential for calculating throughput and intake rates. Where to get Jira Issue Table: Created Date timestamp or History Tab: Issue Created event Capture Logged when the issue creation transaction is committed Event type explicit
	Resolution Verified	The confirmation that the fix effectively solved the problem. Inferred from a status transition to 'Resolved' or a specific 'Verified' state.
Why it matters Quality gate ensuring the fix works. Delays here indicate bottlenecks in testing or user acceptance. Where to get Jira Issue History: Status changed to 'Resolved' or 'Verified' Capture Compare status field updates Event type inferred
	Root Cause Identified	The point where the underlying cause is formally recorded. This is inferred from a status change to 'Root Cause Identified' or the population of the 'Root Cause' field.
Why it matters A major milestone that ends the investigation phase. Essential for calculating 'Mean Time to Root Cause Discovery'. Where to get Jira Issue History: Status changed to 'Root Cause Identified' OR Field 'Root Cause' populated Capture Compare status field or check for field population Event type inferred
	Workaround Updated	The population or update of the 'Workaround' text field. This event indicates that a temporary fix has been documented.
Why it matters Measures the speed of providing relief to the business. Critical for the 'Workaround Availability Lead Time' KPI. Where to get Jira Issue History: Field 'Workaround' changed (not null) Capture Logged when the Workaround field is modified Event type explicit
	Change Request Linked	The linking of a Request for Change (RFC) to the Problem record. This indicates the initiation of the permanent fix process.
Why it matters Measures the lag between identifying the cause and starting remediation. Supports the 'Change Management Transition Delay' KPI. Where to get Jira Issue Links: Link created with type 'is fixed by' or linking to 'Change' issue type Capture Logged when a link to a Change issue type is created Event type explicit
	Permanent Fix Applied	The transition indicating that the solution has been implemented. This is usually inferred from a status change to 'Implementing' or 'Fixed'.
Why it matters Marks the end of the technical remediation work. Used to measure the implementation cycle time. Where to get Jira Issue History: Status changed to 'Implemented', 'Pending Verification', or 'Fixed' Capture Compare status field updates Event type inferred
	Post Implementation Review	The execution of a review after the fix is applied. Captured via a status change to 'In Review' or updates to PIR-specific fields.
Why it matters Compliance activity ensuring lessons learned are captured. Supports 'Post Implementation Review Compliance' analysis. Where to get Jira Issue History: Status changed to 'In Review' OR Field 'PIR Notes' updated Capture Compare status field or PIR field updates Event type inferred
	Problem Priority Changed	An update to the Priority field of the problem record. This is captured by monitoring the history tab for changes to the 'Priority' field.
Why it matters Indicates escalation or de-escalation of the issue. Analyzing this helps identify initial triage accuracy and high-priority backlog aging. Where to get Jira Issue History: Field 'Priority' changed from Old Value to New Value Capture Logged when the Priority field is updated Event type explicit
	Problem Reopened	The transition of a problem from a 'Resolved' or 'Closed' status back to an active status. Indicates a failed fix or rejected resolution.
Why it matters A primary quality metric. High reopen rates indicate ineffective root cause analysis or testing. Where to get Jira Issue History: Status changed from 'Closed'/'Resolved' to 'Open'/'In Progress' Capture Compare status field sequence Event type inferred
	SLA Breached	An event indicating the problem resolution time exceeded the defined Service Level Agreement. This is calculated by comparing the SLA target date with the resolution date.
Why it matters Critical for compliance reporting. Helps identify which priorities or categories most frequently miss targets. Where to get Jira Service Management SLA Logs: 'Time to Resolution' > Target, or calculated Capture Derive from SLA field data or compare Due Date to Resolution Date Event type calculated

Recommended Optional

Extraction Guides

How to get your data from Jira Service Management

Steps

Log in to your Jira Service Management instance using a web browser with an account that has 'Browse Projects' permissions for the Problem Management project.
Navigate to the top menu bar and select Filters, then click on Advanced Issue Search to open the Issue Navigator.
Switch the search mode to JQL (Jira Query Language) rather than Basic if not already selected.
Input the specific JQL query string provided in the Query section below to isolate Problem records (e.g., project = 'Problem Management'). Ensure the time range is appropriate for the system's export limits.
Click the Search button to verify the list of issues returns the expected Problem records.
Locate the Export button in the top right corner of the issue navigator interface.
Select Export XML from the dropdown menu. Do not select CSV, as the standard CSV export only provides current state data and lacks the historical change logs required for process mining.
Save the generated XML file (e.g., jira_export.xml) to a local directory accessible by your processing environment.
Prepare the Python environment by installing the required library pandas if not already present.
execute the Python script provided in the Query section, ensuring the file path variable matches your saved XML file location.
The script parses the RSS/XML structure, extracting the 'Created' timestamp, 'History' entries for status/priority/assignment changes, and 'Issue Links' for related incidents.
The script calculates SLA breaches by comparing resolution dates against due dates and outputs a formatted CSV event log ready for ProcessMind.

Configuration

Export Format: Must use XML (RSS) export, not CSV. The XML format contains the <history> and <issuelinks> tags essential for reconstructing the process flow.
Row Limit: Jira standard exports are often limited to 1,000 issues per export. For larger datasets, you must paginate the extraction by adjusting the JQL date range (e.g., created >= '2023-01-01' AND created < '2023-02-01') and performing multiple exports.
JQL Filter: Ensure the project key matches your specific Problem Management project identifier (e.g., PROB, PM).
System Timezone: Verify the user profile performing the export matches the system timezone to ensure timestamp consistency.
Field Permissions: The user must have permission to view the Change History and Linked Issues to capture transitions and Incident links.
Custom Fields: If 'Root Cause' or 'Workaround' are custom fields, ensure the script's field name matching logic aligns with the specific field names in your Jira instance.

a Sample Query config

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

Steps

Prerequisites Setup: Ensure you have Python 3.x installed along with the requests and pandas libraries. You will need a Jira Service Management account with read permissions for the relevant project. For Jira Cloud, generate an API Token via your Atlassian Account settings. For Data Center, generate a Personal Access Token (PAT).
Identify Custom Field IDs: Jira Service Management uses dynamic IDs for custom fields (e.g., customfield_10012 for Support Group or SLA). Before running the main extraction, use a browser or Postman to query one specific Problem issue (/rest/api/2/issue/[ISSUE-KEY]) to identify the specific field IDs for 'Support Group', 'Workaround', 'Root Cause', and your SLA fields.
Configure the Script: Open the provided Python script and update the CONFIG dictionary. Replace the URL, User Email, and API Token. Update the FIELD_MAPPING dictionary with the actual custom field names or IDs you identified in Step 2. Update the JQL_QUERY to target your specific project (e.g., project = PM AND issuetype = Problem).
Define Status Mappings: In the STATUS_MAPPING dictionary within the script, map your specific Jira workflow statuses (e.g., 'Under Investigation', 'Implementing', 'Resolved') to the standard ProcessMind activity names (e.g., 'Investigation Started', 'Permanent Fix Applied').
Run the Extraction: Execute the script via a terminal or IDE. The script uses the Jira Search API with expand=changelog to pull the current state and the full history of every field change.
Processing Logic: The script iterates through every issue. It first creates a 'Problem Record Created' event from the creation timestamp. It then parses the changelog history. For every history item, it checks if the changed field matches our interest list (Status, Priority, Link, etc.) and generates a corresponding event row.
SLA Handling: The script attempts to identify SLA breaches by looking for changes in SLA-related custom fields or status transitions explicitly named 'Breached'. Adjust the logic in the _parse_sla_breach function if your system uses a specific automation to flag breaches.
Data Transformation: The script flattens the nested JSON structure into a tabular Pandas DataFrame. Timestamps are converted to ISO 8601 format.
Export: The final dataset is exported to a CSV file named jira_problem_event_log.csv. Open this file to verify the column headers match the ProcessMind requirements.
Upload to ProcessMind: Import the CSV file into ProcessMind. Map ProblemKey as Case ID, ActivityName as Activity, and EventTimestamp as Timestamp.

Configuration

API Endpoint: Uses /rest/api/2/search (compatible with Cloud and most Data Center versions). API v3 is also supported but v2 is generally safer for broad compatibility.
Pagination: The script implements pagination using startAt and maxResults to handle large datasets efficiently. Default batch size is set to 50.
Changelog Expansion: The parameter expand=changelog is critical. Without this, only the current state is returned, and history/process flow is lost.
JQL Filtering: The query filters by issuetype = Problem. It is highly recommended to add a date range filter (e.g., created >= -180d) to limit data volume during initial testing.
Authentication: Supports Basic Auth (Email + Token) for Cloud. For Data Center, modify the headers to use Bearer tokens.
Field Mapping: Critical configuration required. Jira internal field names for 'Status' and 'Priority' are standard, but 'Support Group', 'Root Cause', and 'SLA' are almost always custom fields with unique IDs (e.g., customfield_12345).

a Sample Query python

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

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        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(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

Your Problem Management Data Template

Your Problem Management Data Template

Problem Management Attributes

Problem Management Activities

Extraction Guides

Jira Service Management Issue Navigator Export

Steps

Configuration

a Sample Query config

Python Extraction via Jira REST API with Changelog

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize Your Problem Management Flow Today

Your Problem Management Data Template

Your Problem Management Data Template

Problem Management Attributes

Problem Management Activities

Extraction Guides

Jira Service Management Issue Navigator Export

Steps

Configuration

a Sample Query config

Python Extraction via Jira REST API with Changelog

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Optimize Your Problem Management Flow Today