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

Your Service Request Management Data Template

Jira Service Management

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

Your Service Request Management Data Template

This template provides a structured approach to collecting the essential data needed for analyzing your service request processes. It outlines the crucial attributes to gather, the key activities to track, and provides guidance on how to extract this information from your system. Use this resource to streamline your data preparation and gain deeper insights into your operations.

Recommended attributes for comprehensive analysis
Key activities to track for process discovery
Extraction guidance for Jira Service Management

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

Download Template

Service Request Management Attributes

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

5 Required 5 Recommended 10 Optional

	Name	Description
	Activity ActivityName	The name of the specific event or task that occurred within the service request lifecycle.
Description This attribute describes the specific action or status transition that took place at a point in time for a service request. Examples include 'Request Created', 'Request Assigned', 'Solution Implemented', and 'Request Closed'. Analyzing the sequence and frequency of these activities is the core of process mining. It allows for the visualization of process maps, identification of bottlenecks, and detection of deviations from the standard workflow, which is critical for understanding process efficiency and compliance. Why it matters It defines the steps in the process, enabling the visualization of the process map and the analysis of workflow patterns and deviations. Where to get Typically derived from the 'status' transition history of a Jira issue. Each entry in the issue's changelog for the status field represents an activity. Examples Request TriagedInformation RequestedSolution ImplementedService Request Closed
	Service Request ID ServiceRequestId	The unique identifier for each service request, serving as the primary key for all related events.
Description The Service Request ID, often called the Issue Key in Jira, uniquely identifies each individual service request submitted by a user or system. It serves as the central thread linking all subsequent events, from initial logging to final closure, allowing for a complete, end-to-end analysis of each service request's journey. In process mining, this ID is essential for case correlation. It ensures that every activity, status change, and timestamp is correctly associated with the specific request it belongs to, forming a coherent process instance for analysis. Why it matters This ID is the fundamental case identifier that connects all related activities into a single end-to-end process flow, making process analysis possible. Where to get This is the 'key' field for an issue in Jira Service Management. Examples SR-2023-001IT-45892HELP-105
	Start Time EventTime	The precise date and time when a specific activity or event occurred.
Description The Start Time, or event timestamp, records the exact moment an activity happened. This is a critical component for any process mining analysis, as it provides the temporal context for the entire process. This timestamp is used to order events sequentially, calculate the duration between activities, measure total case cycle times, and analyze process performance against time-based targets like SLAs. Without accurate timestamps, it is impossible to understand process flow, identify delays, or measure efficiency. Why it matters This timestamp is essential for ordering events, calculating durations and cycle times, and identifying process bottlenecks. Where to get This is the timestamp associated with each status transition in the Jira issue changelog. The issue creation time is the 'created' field. Examples 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Last Data Update LastDataUpdate	The timestamp indicating when the data was last refreshed from the source system.
Description This attribute records the date and time of the most recent data extraction from Jira Service Management. It provides crucial context for the freshness of the analysis and the data contained within the dashboards and KPIs. In any analysis, knowing the data's timeliness is essential for making informed decisions. This timestamp helps users understand if they are looking at real-time information or a snapshot from a previous point in time, which affects the relevance of the findings. Why it matters Indicates the freshness of the data, ensuring that analyses are based on up-to-date information. Where to get This is a metadata field generated and stored by the data extraction tool or script at the end of its run. Examples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Source System SourceSystem	The system from which the service request data was extracted.
Description This attribute identifies the origin of the data, which in this case is Jira Service Management. While it may seem trivial when analyzing data from a single source, it becomes crucial when merging process data from multiple systems. For analysis, it helps in tracing data lineage and ensuring data quality. It also allows for filtering and comparing processes that might span or interact with different software platforms. Why it matters Identifies the data's origin, which is crucial for data governance and when combining process data from multiple enterprise systems. Where to get This is typically a static value added during the data extraction and transformation process to label the dataset's origin. Examples Jira Service ManagementJiraSM
	Assignee Assignee	The user or agent currently assigned to work on the service request.
Description The Assignee is the individual responsible for the next action or the resolution of the service request. The value of this attribute can change multiple times throughout the request's lifecycle as it is handed off between different agents or teams. This attribute is critical for workload analysis, performance measurement, and resource management. It allows for filtering the process by agent, comparing resolution times across individuals, and identifying potential training needs or workload imbalances that cause bottlenecks. Why it matters This attribute is vital for analyzing agent workload, measuring individual performance, and understanding resource allocation. Where to get This corresponds to the 'assignee' field on a Jira issue. Examples Alice JohnsonBob WilliamsUnassigned
	Request Priority RequestPriority	The priority level assigned to the service request, such as Low, Medium, High, or Critical.
Description Request Priority indicates the urgency and business impact of a service request. This classification determines the order in which requests are handled and often dictates the target resolution times and SLAs. In process analysis, priority is a key dimension for segmentation. It allows for comparing cycle times and SLA adherence across different priority levels, ensuring that high-priority requests are indeed being processed faster and meeting their targets. This helps validate the effectiveness of the prioritization system. Why it matters Allows for segmenting analysis to ensure that high-priority requests are handled more quickly and meet stricter service levels. Where to get This corresponds to the 'priority' field on a Jira issue. Examples HighestHighMediumLow
	Request Status RequestStatus	The current status of the service request in its lifecycle.
Description This attribute represents the current state of a service request, such as 'Open', 'In Progress', 'Waiting for Customer', or 'Resolved'. It provides a snapshot of where the request is at any given time. While the activity log provides the historical flow, the current status is useful for analyzing open workloads and identifying items that are stuck. For example, analysis can focus on requests that have been in the 'Waiting for Vendor' status for an unusually long time, highlighting external dependencies and delays. Why it matters Provides a current snapshot of each case, enabling analysis of work-in-progress and identifying stalled or aging requests. Where to get This is the 'status' field on a Jira issue. Examples OpenIn ProgressPending CustomerResolved
	Request Type RequestType	The classification of the service request, such as 'Access Request' or 'Hardware Issue'.
Description Request Type categorizes the service request based on its nature. This is a fundamental dimension for analysis, as different types of requests often have distinct resolution processes, SLAs, and resource requirements. By segmenting the process analysis by Request Type, organizations can tailor improvements to specific workflows. For instance, the bottleneck for a 'Password Reset' request will be very different from that of a 'New Server Provisioning' request. This attribute is key to building relevant dashboards like 'Resolution Quality by Category'. Why it matters This attribute is essential for comparing processes, workloads, and performance across different categories of service requests. Where to get This often corresponds to the 'issuetype' field in Jira or a custom 'Request Type' field in Jira Service Management. Examples Request a new accountGet IT helpOnboard a new employee
	SLA Due Date SlaDueDate	The target date and time by which the service request should be resolved according to its SLA.
Description The SLA Due Date is a calculated timestamp that represents the deadline for resolving a request. This is determined by the request's priority, type, and the specific Service Level Agreement (SLA) policies configured in Jira Service Management. This attribute is fundamental for the 'Service Request SLA Performance' dashboard and the 'SLA Adherence Rate' KPI. By comparing the actual resolution time with this due date, the system can determine whether each request was completed on time, was late, or is at risk of breaching its SLA. Why it matters This is the benchmark for measuring performance. It directly supports the calculation of SLA compliance and helps prioritize work. Where to get SLA information is managed by Jira Service Management and is accessible via the API, often stored in custom fields that update dynamically. Examples 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Assigned Team AssignedTeam	The team or group responsible for handling the service request.
Description This attribute specifies the team assigned to a request, which is often a higher-level grouping than the individual assignee. This is useful for analyzing performance at a team level, such as comparing the First-Level Support team with the Network Operations team. This dimension is crucial for dashboards like 'Agent Workload and Resolution Metrics'. It allows for aggregating performance metrics at the team level, facilitating fair comparisons and understanding how different teams contribute to the overall service delivery process. Why it matters Enables performance analysis and workload balancing at a team or department level, rather than just by individual agent. Where to get This may be a custom field in Jira (e.g., 'Team') or derived from the assignee's user profile attributes. Examples IT Support - Tier 1Infrastructure TeamApplication Support
	Case Cycle Time CaseCycleTime	The total time elapsed from the creation to the final closure of a service request.
Description Case Cycle Time is a calculated metric that measures the total duration of a service request's lifecycle. It is typically calculated as the difference between the 'Service Request Closed' timestamp and the 'Service Request Created' timestamp. This is one of the most important KPIs in process mining, directly supporting the 'Average Service Request Cycle Time' KPI and the 'Service Request End-to-End Cycle Time' dashboard. It provides a high-level measure of overall process efficiency and customer wait time. Why it matters This is a primary KPI for measuring overall process efficiency and the end-to-end customer experience. Where to get Calculated during data transformation by subtracting the creation timestamp from the final closed timestamp for each case. Examples 864003600007200
	Channel Channel	The submission method used to create the service request, such as Email, Portal, or API.
Description The Channel attribute identifies how a service request entered the system. Common channels in Jira Service Management include the customer portal, email, or direct creation by an agent. Analyzing the process by channel is important for understanding user behavior and optimizing service delivery. It can reveal if requests from certain channels take longer to resolve or require more clarification, potentially indicating a need for better forms on the portal or improved email parsing rules. This supports the 'Service Request Throughput Trends' dashboard. Why it matters Helps analyze if the submission channel impacts resolution times, request clarity, or overall process efficiency. Where to get This information is available in Jira Service Management via the 'Request channel type' field. It may require specific API access or be stored in a custom field. Examples portalemailapi
	Is Reopened IsReopened	A boolean flag that indicates if a service request was reopened after being resolved.
Description This calculated attribute is a true/false flag that is set to true if a request's workflow includes a 'Request Reopened' activity. It is derived by analyzing the sequence of activities for each case. This flag is essential for calculating the 'Service Request Reopen Rate' KPI and for powering the 'Reopened Service Request Volume' dashboard. A high reopen rate is a strong indicator of poor first-time resolution quality, leading to rework and decreased customer satisfaction. Analyzing which types of requests or resolutions are associated with this flag can pinpoint areas for improvement. Why it matters Directly measures rework and first-time resolution quality, which are key indicators of process effectiveness and customer satisfaction. Where to get Calculated during data transformation by checking if the sequence of activities for a case contains a 'Reopened' transition after a 'Resolved' transition. Examples truefalse
	Organization Organization	The customer organization or internal department that the reporter belongs to.
Description This attribute groups reporters into organizations or departments. Jira Service Management has a built-in 'Organizations' feature that allows agents to manage requests from multiple customers or internal teams. Analyzing by organization provides valuable business context. It can help identify which customers or departments consume the most support resources, whether any specific groups are experiencing recurring issues, and if SLAs are being met consistently across different business units. Why it matters Facilitates analysis of service demand and performance by customer or internal department, providing key business insights. Where to get This data comes from the 'Organizations' field associated with the service request in Jira Service Management. Examples Acme CorporationFinance DepartmentGlobal Tech Inc.
	Reporter Reporter	The user who initially created or reported the service request.
Description The Reporter is the individual, often an end-user or customer, who submitted the service request. This attribute identifies the stakeholder who initiated the process. In analysis, the Reporter can be used to understand request patterns from different users, departments, or customer segments. It helps answer questions like 'Which departments submit the most requests?' or 'Are specific users repeatedly facing the same issues?'. This information is valuable for proactive problem management and improving user training. Why it matters Identifies the request originator, enabling analysis of request volumes and types by user, department, or customer. Where to get This corresponds to the 'reporter' field on a Jira issue. Examples Charles DarwinMarie CurieIsaac Newton
	Resolution Resolution	The final outcome or conclusion of a resolved service request.
Description The Resolution field indicates why a service request was closed. Common values include 'Done', 'Won't Do', 'Duplicate', or 'Cannot Reproduce'. It provides closure details beyond just a 'Resolved' or 'Closed' status. Analyzing resolutions helps in understanding the quality and nature of outcomes. For example, a high number of 'Duplicate' resolutions might signal an issue with the request submission process, while tracking which resolutions lead to reopened requests can highlight ineffective solutions. Why it matters Provides context on the outcome of a request, helping to analyze resolution quality and identify trends in why requests are closed. Where to get This corresponds to the 'resolution' field on a Jira issue, which is typically set when the issue transitions to a 'done' status category. Examples DoneWon't DoDuplicateFixed
	SLA State SlaState	Indicates whether the service request met, breached, or is within its defined SLA.
Description SLA State is a calculated attribute that categorizes each service request based on its performance against its SLA deadline. Possible values include 'Met', 'Breached', or 'In Progress'. It is determined by comparing the resolution timestamp to the 'SlaDueDate'. This is the core attribute for the 'Service Request SLA Performance' dashboard and is used to calculate the 'SLA Adherence Rate' KPI. It provides a clear, at-a-glance view of service level compliance, which is critical for reporting, contract management, and maintaining service quality. Why it matters Provides a clear and immediate indicator of SLA performance, which is a critical measure of service quality and contractual compliance. Where to get Calculated during data transformation. If the resolution time is before the 'SlaDueDate', the state is 'Met'; otherwise, it is 'Breached'. Examples MetBreachedIn Progress
	Triage to Assignment Time TriageToAssignmentTime	The duration between when a request was triaged and when it was assigned to an agent.
Description This is a calculated duration metric that measures the efficiency of the initial handling and routing phase of a service request. It is calculated as the time difference between the 'Request Assigned' activity and the 'Request Triaged' activity. This metric is the basis for the 'Average Triage-to-Assignment Time' KPI and the 'Triage and Assignment Efficiency' dashboard. A long duration here can indicate a bottleneck in the service desk's intake process, such as insufficient staff for triaging or delays in determining the correct team for assignment. Why it matters Measures the efficiency of the crucial first steps of request handling, highlighting delays before work can even begin. Where to get Calculated during data transformation by subtracting the timestamp of the 'Request Triaged' event from the 'Request Assigned' event. Examples 3009001800
	Vendor Engagement Duration VendorEngagementDuration	The total time a service request spent waiting on an external vendor.
Description This is a calculated metric that sums the total time a service request was in a state indicating it was with an external vendor. It is calculated by finding the duration between 'Vendor Engagement Started' and 'Vendor Engagement Ended' activities, and summing these durations if they occur multiple times within a single case. This attribute is essential for the 'External Vendor Engagement Delays' dashboard and the 'Average External Vendor Time' KPI. It helps quantify delays caused by third-party dependencies, which is critical for managing vendor relationships and setting realistic customer expectations. Why it matters Isolates and quantifies delays caused by external dependencies, providing data to manage vendor performance and improve forecasting. Where to get Calculated during data transformation by measuring the time between 'Vendor Engagement Started' and 'Vendor Engagement Ended' events. Examples 172800604800259200

Required Recommended Optional

Service Request Management Activities

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

5 Recommended 8 Optional

	Activity	Description
	Request Assigned	This activity occurs when a service request is assigned to a specific agent or team for resolution. Jira explicitly tracks changes to the 'Assignee' field, providing a clear timestamp for when the assignment was made.
Why it matters This is a key milestone for measuring Triage-to-Assignment time and agent workload distribution. It marks the transition from queuing to active handling. Where to get Captured from the issue history by looking for the first instance of the 'Assignee' field being set or changed from unassigned. Capture Use the timestamp of the first 'Assignee' field change in the issue history. Event type explicit
	Resolution Proposed	In many service desk workflows, this is a distinct step where a solution is offered to the requestor for their approval. This is inferred when the issue status changes to a state like 'Pending Customer Acceptance' or 'Awaiting Confirmation'.
Why it matters This activity isolates the time spent waiting for customer feedback after a solution has been provided, helping to differentiate it from internal work time. Where to get Inferred from the issue history, captured at the timestamp when the status changes to a state indicating the solution is pending customer validation. Capture Identify timestamp of status change to 'Pending Customer Acceptance' or equivalent. Event type inferred
	Service Request Closed	Represents the final, administrative closure of the service request, often occurring automatically after a set period in the 'Resolved' state. This is the terminal point of the issue's lifecycle in Jira.
Why it matters This is the definitive end event of the process. The time between 'Resolved' and 'Closed' can be analyzed to understand administrative overhead or auto-closure policies. Where to get Inferred from the issue history. The timestamp corresponds to the final status change to 'Closed' or an equivalent terminal status. Capture Identify the timestamp of the final status change to a 'Closed' status. Event type inferred
	Service Request Created	This activity marks the beginning of the service request lifecycle when a user formally submits a request through a portal, email, or other channel. This event is captured explicitly in Jira when a new issue of the 'Service Request' type is created, recording the creation timestamp.
Why it matters This is the primary start event for the process. It is essential for calculating the overall cycle time and understanding request volume and arrival patterns. Where to get This is an explicit event captured in the issue history table. The activity timestamp is the 'created' field on the Jira issue. Capture Use the issue creation timestamp from the 'issues' table or history. Event type explicit
	Service Request Resolved	Marks the official point in time when the request is considered fulfilled and the solution is recorded. Jira populates the 'Resolution Date' field when an issue enters a status of the 'Done' category for the first time.
Why it matters This is a primary end milestone for the process, critical for calculating resolution time and SLA adherence. It signifies the end of active work. Where to get This is an explicit event. The timestamp is the value in the 'Resolution Date' field of the Jira issue, which is set upon the first transition to a 'Done' category status. Capture Use the 'resolutiondate' field from the Jira issue. This field is populated automatically. Event type explicit
	Information Provided	Occurs when the requestor responds with the necessary information, allowing the agent to resume work. This is inferred when the issue moves out of a 'Waiting for customer' status, often triggered by the requestor adding a comment.
Why it matters This activity completes the request-response loop with the customer. The time between requesting and receiving information is a key component of process waiting time. Where to get Inferred from the issue history. The timestamp corresponds to when the issue's status changes from 'Waiting for customer' back to an 'In Progress' state. Capture Identify the timestamp when the 'status' field changes from a 'waiting' state back to an 'active' state. Event type inferred
	Information Requested	Marks the point when an agent requires more information from the requestor to proceed with the resolution. This is typically inferred by the issue transitioning to a status like 'Waiting for customer' or 'Pending Input'.
Why it matters Frequent or lengthy 'Information Requested' cycles can indicate unclear initial submissions or inefficient communication, representing a significant source of delays. Where to get Inferred from the issue history. The timestamp corresponds to when the issue's status changes to 'Waiting for customer' or an equivalent status. Capture Identify the timestamp when the 'status' field changes to a value indicating the process is waiting on the customer. Event type inferred
	Request Reopened	This activity captures instances where a previously resolved service request is returned to an active state. It is inferred by a status change from a resolved or closed state back to an open or in-progress state.
Why it matters Tracking reopened requests is critical for measuring resolution quality and First-Time Resolution Rate. A high reopen rate indicates ineffective solutions or recurring issues. Where to get Inferred from the issue history by identifying a status transition from a 'Resolved' or 'Closed' category status to an 'Open' or 'In Progress' category status. Capture Look for a status change from a 'Done' status category to a 'To Do' or 'In Progress' status category. Event type inferred
	Request Triaged	Represents the initial assessment of a service request, where its priority, category, and impact are determined. This activity is typically inferred from a status change, such as moving from 'New' to 'In Progress' or a dedicated 'Triaged' status.
Why it matters Analyzing the time to triage helps evaluate the efficiency of the initial request handling process. Delays here can significantly impact overall resolution times and SLA adherence. Where to get Inferred from the issue history by identifying the first timestamp of a status change from an initial 'New' or 'Open' state to an active state like 'In Progress'. Capture Identify the first status change from 'New' or an equivalent initial status based on the project's workflow. Event type inferred
	Resolution Confirmed	Occurs when the requestor formally accepts the proposed solution, often triggering an automated transition to the 'Resolved' status. This event is typically inferred from this status change.
Why it matters This milestone validates the effectiveness of the solution and is the trigger for stopping the SLA clock. It helps measure the time customers take to confirm fixes. Where to get Inferred from the issue history. The timestamp corresponds to the status changing from 'Pending Customer Acceptance' to 'Resolved' or 'Closed'. Capture Identify timestamp of status change from 'Pending Customer Acceptance' to a 'Resolved' or 'Closed' status. Event type inferred
	Solution Implemented	Indicates that the agent has performed the necessary actions or developed a solution to address the service request. This is often inferred from a status change to 'Pending Review' or directly to 'Resolved'.
Why it matters This milestone marks the completion of the core resolution work. The time leading up to this activity often represents the primary value-add portion of the process. Where to get Inferred from the issue history, corresponding to the timestamp of the status change to 'Resolved', 'Pending Acceptance', or a similar pre-closure status. Capture Identify the timestamp when the 'status' field changes to a value indicating the work is complete. Event type inferred
	Vendor Engagement Ended	Represents the moment when the external vendor has completed their action and the service request is returned to the internal team. This is inferred when the issue moves out of the 'Waiting for vendor' status.
Why it matters Measuring the duration of vendor engagement helps in managing vendor performance and understanding the impact of external parties on overall resolution times. Where to get Inferred from the issue history. The timestamp corresponds to when the issue's status changes from a 'vendor' status back to an 'In Progress' state. Capture Identify the timestamp when the 'status' field changes from a 'vendor' state back to an 'active' state. Event type inferred
	Vendor Engagement Started	This activity signifies that the service request has been escalated to or requires action from an external vendor or third party. It is inferred from the issue transitioning to a status like 'Waiting for vendor' or 'With Third Party'.
Why it matters Tracking vendor engagement is crucial for identifying external dependencies and delays that are outside the direct control of the internal service desk. Where to get Inferred from the issue history. The timestamp corresponds to when the issue's status changes to a designated 'vendor' status. Capture Identify the timestamp when the 'status' field changes to a value like 'Waiting for Vendor'. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Jira Service Management

Steps

Log in to your Jira Service Management instance and navigate to the main menu.
Select Filters and then choose Advanced issue search. This will open the Issue Navigator where you can build queries.
In the search bar, enter the JQL (Jira Query Language) query provided in the Query section to filter for the specific service requests you wish to analyze. Adjust the project key and date range as needed.
Click the Search button to execute the query. Review the list of issues returned to ensure it is the correct dataset.
In the top right corner of the search results page, click the Export icon (often looks like a box with an arrow pointing out).
From the dropdown menu, select XML. It is critical to use XML, as the standard CSV export does not contain the detailed change history required to generate a complete event log.
Save the downloaded XML file to your local system. This file contains all the issues from your query, with their full change history embedded within each issue's data.
Because the exported XML is not in an event log format, a post-processing step is required. Use a script (for example, in Python, Powershell, or another language) to parse the XML file.
The script must iterate through each issue in the file and create a 'Service Request Created' event from the created timestamp. Then, it must parse the changelog history for each issue, identifying field changes for 'status' and 'assignee' that map to the required activities. For each identified change, a new row must be generated.
The script should transform this data into a flat CSV file, creating columns for ServiceRequestId, ActivityName, EventTime, and all other required and recommended attributes.
The final output from your script is the event log. Save this CSV file and prepare it for upload into the process mining tool.

Configuration

JQL Project Filter: Use project = "[Your JSM Project Key]" to target the specific service management project. Replace the placeholder with your project's key, for example, 'JSM' or 'HELPDESK'.
JQL Issue Type Filter: Use issuetype = "Service Request" or the specific name of the issue type used for service requests in your configuration.
Date Range: It is highly recommended to filter by a specific time period to manage the export size. Use a clause like created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". A range of 3 to 6 months is often a good starting point.
Export Format: You must select XML for the export. The CSV format does not include the changelog data necessary for creating the event log.
Jira Permissions: The user performing the export must have 'Browse Projects' permission for the specified Jira project to view and export issues.
Data Volume: Jira's default UI export is often limited to 1000 issues at a time. If your query returns more results, you must export the data in smaller batches by narrowing the date range for each export.

a Sample Query config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

Steps

Gain Database Access: Obtain read-only credentials and connection details (hostname, port, database name) for the Jira instance's backend SQL database. This typically requires assistance from a database administrator or your IT department.
Identify Jira Schema: Connect to the database using a SQL client like DBeaver, SQuirreL SQL, or SQL Server Management Studio. Familiarize yourself with key tables: jiraissue (core issue data), changegroup (history of changes), changeitem (details of each change), project (project details), issuetype, and priority.
Locate Custom Field IDs: Attributes like RequestType and SlaDueDate are often custom fields. Identify their IDs by querying the customfield table: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Note these IDs for use in the main query.
Customize the SQL Query: Copy the provided SQL script into your SQL client. You must carefully replace all placeholder values, which are enclosed in square brackets, with the actual values from your Jira configuration. This includes project keys, issue type names, status names, and custom field IDs.
Set the Date Range: Locate the WHERE i.created >= '[YYYY-MM-DD]' clause in the initial issue_base part of the query. Modify the date to define the time window for your data extraction.
Execute the Query: Run the modified SQL script. The query is designed to run on common SQL databases like PostgreSQL, SQL Server, and MySQL. It might take several minutes to complete on large Jira instances.
Review the Results: Once the query finishes, briefly inspect the output to ensure it returns rows and that columns like ServiceRequestId, ActivityName, and EventTime are populated as expected.
Export the Data: Export the full result set from your SQL client to a CSV file. Name the file something descriptive, such as jira_servicerequest_eventlog.csv.
Prepare for Upload: Open the CSV file and verify that the column headers match the required attribute names exactly, for example, ServiceRequestId, ActivityName, EventTime. Ensure the file is saved with UTF-8 encoding for compatibility with ProcessMind.

Configuration

Prerequisites: Direct, read-only access to the Jira production or replica database is required. Standard application access is not sufficient. You will also need a comprehensive understanding of your specific Service Desk project's workflow, including the exact names of statuses, issue types, and custom fields.
Key Query Filters: The query must be configured to target the correct data set. Pay close attention to these WHERE clauses:
- p.pkey IN ('[Your Project Key]'): This is the most important filter. It restricts the data to one or more specific Jira Service Management projects.
- it.pname = '[Your Service Request Issue Type]': This ensures you are only extracting service requests and not incidents, problems, or other issue types.
- i.created >= '[YYYY-MM-DD]': This filter sets the start date for the extraction. For an initial analysis, a range of the last 3 to 6 months is recommended.
Workflow Status Mapping: The accuracy of the event log depends entirely on correctly mapping your Jira status names in the query. You must replace placeholders like [Status for Triage], [Waiting for Customer Status], and [Resolved Status] with the names used in your specific workflow.
Performance Considerations: Executing this query directly against a large, active Jira database can consume significant resources and potentially impact application performance for users. It is highly recommended to run the extraction against a read-replica database or during off-peak hours.

a Sample Query sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

Steps

Prerequisites and Setup: Ensure you have Python 3.6 or newer installed on your system. Install the necessary Python libraries by running the following command in your terminal: pip install requests pandas.
Generate a Jira API Token: Log in to your Jira Cloud account. Navigate to your profile settings, select 'Account settings', then go to the 'Security' tab and create an API token. Copy this token securely, as it will be used for authentication.
Identify Custom Field IDs: Many Jira attributes like 'Request Type' or 'SLA Due Date' are custom fields. To find their IDs, navigate to 'Settings' > 'Issues' > 'Custom fields'. Search for your desired field and click the three dots '...' > 'View field information'. The ID will be in the URL (e.g., customFieldId=10021). Note these IDs for the script configuration.
Configure the Python Script: Open the provided Python script in a text editor. Fill in the configuration variables at the top of the file, including JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, the jql_query to select your service requests, and the CUSTOM_FIELD_IDS you identified in the previous step.
Map Jira Statuses to Activities: Critically review the STATUS_ACTIVITY_MAP dictionary in the script. You must update this mapping to match your specific Jira Service Management workflow. The keys should be the exact names of your Jira statuses (e.g., 'Waiting for customer'), and the values should be the corresponding activity names required for the event log (e.g., 'Information Requested').
Execute the Extraction Script: Open a terminal or command prompt, navigate to the directory where you saved the script, and run it using the command: python jira_extraction_script.py. The script will connect to the Jira API, fetch the issue data, process it, and print progress updates to the console.
Review the Output File: Once the script completes, it will generate a CSV file named jira_event_log.csv in the same directory. Open this file in a spreadsheet application to verify its contents. Check that all columns are present and populated as expected.
Prepare for ProcessMind Upload: Ensure the column headers in the CSV file exactly match the requirements: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType, and SlaDueDate. The file is now ready to be uploaded to ProcessMind.

Configuration

Jira Authentication: The script requires your Jira domain URL, the email address associated with your Jira account, and a personal API token for secure access.
JQL Query (jql_query): This is the core filter for your extraction. It is crucial to define a precise JQL query to select the correct issues. We recommend filtering by project, issuetype, and a specific date range using createdDate to manage the data volume (e.g., project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m').
Status to Activity Mapping (STATUS_ACTIVITY_MAP): This dictionary is essential for correctly translating Jira status changes into meaningful process activities. You must customize this mapping to reflect your organization's specific Jira workflow. Any status not in this map will be ignored.
Custom Field IDs (CUSTOM_FIELD_IDS): To extract data from custom fields like 'Request Type' or 'SLA Due Date', you must provide their unique system IDs (e.g., customfield_10021). These must be configured correctly for the attributes to be populated.
Date Range and Performance: For initial extractions, it is recommended to use a JQL date range of 3 to 6 months to ensure manageable performance. Extracting several years of data can be slow due to API pagination and rate limiting.

a Sample Query python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{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'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

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

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Jira Service Management Built-in CSV/XML Export

Steps

Configuration

a Sample Query config

Direct Database Query on Jira Server/Data Center

Steps

Configuration

a Sample Query sql

Python Script Extraction via Jira Cloud REST API

Steps

Configuration

a Sample Query python

Ready to Get Started?

Optimize Service Request Management in Jira Now

Your Service Request Management Data Template

Your Service Request Management Data Template

Service Request Management Attributes

Service Request Management Activities

Extraction Guides

Jira Service Management Built-in CSV/XML Export

Steps

Configuration

a Sample Query config

Direct Database Query on Jira Server/Data Center

Steps

Configuration

a Sample Query sql

Python Script Extraction via Jira Cloud REST API

Steps

Configuration

a Sample Query python

We value your privacy

Ready to Get Started?

Optimize Service Request Management in Jira Now