Query on MSPowerAutomate Action "Get list of issues" for Jira Connector

[Aslam Mohammed]

We are trying to build a Flow in MSPowerAutomate to get a list of issues when a Trigger condition is met.

We are using the Jira connector in PowerAutomate. The flow is set-up as below.

1) Trigger: When a New Issue is created in a Jira Project

2) Action: Get list of issues

Jira - Connectors | Microsoft Learn

The Microsoft Documentation says 

However, there's only ONE parameter which is for the "Jira instance". 

It doesn't have the option or parameter to set the JQL.

If any of the community members have used the Jira connector and this action, it would be helpful if you have any ideas.

[saishekar peddi]

Automating Jira Deployment Cards to SharePoint: A Free-Tier Approach

Executive Summary: Automating Jira Deployment Cards to SharePoint (Free Tier)

The objective of this report is to detail a practical, cost-effective solution for automating the transfer of "ready for deployment cards" (Jira issues) into a SharePoint sheet. A significant challenge in this automation lies in the explicit requirement to avoid paid versions of Power Automate, which means direct integration with Jira via its premium connector is not a viable option. This necessitates the development of a creative, free-tier workaround.  

This report outlines a solution that leverages Jira's native capability to send JQL query results via email on a scheduled basis. Power Automate, utilizing its standard (free) Outlook and SharePoint connectors, can then process these emails. The core of this approach involves parsing the Jira data from the HTML table embedded within the email body and subsequently updating a designated SharePoint List. This method effectively bypasses premium connector requirements, aligning perfectly with the criteria for "no paid version" and "minimal things." By implementing this solution, organizations can achieve regular, automated updates of critical deployment information in SharePoint, significantly reducing manual effort and ensuring stakeholders have access to up-to-date data. This streamlines the deployment tracking process, providing a centralized view of readiness without incurring additional licensing costs.

Understanding Automation Needs: Streamlining Deployment Tracking

The request for automation, specifically to update a SharePoint sheet with "ready for deployment cards" from Jira, underscores a common organizational need to streamline information flow and enhance visibility for critical processes like software deployments. The user's emphasis on "easy peasy data" and "just few cards" is not merely a preference for simplicity; it also implicitly defines important technical parameters for the solution.

This language suggests that the volume of data to be transferred is expected to be relatively small. This is a crucial consideration, as Power Automate's free tier operates under specific limitations regarding API requests and flow runs. For instance, the free plan typically offers approximately 750 runs per month and a daily limit of 6,000 API requests. Each action within a Power Automate flow consumes API requests. If the "few cards" were to scale to hundreds or thousands of issues, or if the flow needed to run very frequently (e.g., every few minutes), these limits could quickly be exceeded, potentially leading to throttling or flow suspension. Therefore, the solution must be designed to be efficient and mindful of these constraints, setting realistic expectations for scalability from the outset.  

The individual seeking this automation, characterized as a Practical Project Coordinator, typically prioritizes achieving tangible results with available resources. Such a persona values functional and reliable solutions for recurring tasks, such as preparing for deployment calls, and aims to avoid unnecessary complexity or additional costs. The guidance provided in this report is tailored to offer clear, actionable steps that align with this practical, results-oriented mindset, empowering the user to implement the automation with confidence.  

The Free-Tier Solution: Bridging Jira and SharePoint

The absence of a paid Power Automate license necessitates a creative approach to integrate Jira and SharePoint. The proposed solution leverages existing, free-tier capabilities within both platforms.

Leveraging Jira's Native Email Subscriptions

Jira offers a powerful, built-in feature that enables the automated delivery of JQL (Jira Query Language) search results via email on a scheduled basis. This functionality is central to bypassing the premium Jira connector in Power Automate. Organizations can define a specific JQL query (e.g.,  

status = "Ready for Deployment") to precisely filter the desired Jira issues. Once this filter is saved, a subscription can be created, specifying the frequency (e.g., daily, weekly) and the recipient email address. This automated email will serve as the primary data source for the Power Automate flow.  

A critical aspect of this method is understanding the format of the email content. Jira filter subscriptions typically send the search results as a CSV-formatted HTML table embedded directly within the email body, rather than as a direct .csv file attachment. While some discussions mention the possibility of attaching a  

.csv file, achieving this usually involves more complex scripting within Jira itself. For an "easy peasy" approach, the solution assumes the standard HTML table format. This distinction is vital because Power Automate will need to be configured to parse HTML content, not a straightforward CSV file.  

Power Automate's Standard Connectors: Outlook and SharePoint

The foundation of this free-tier automation lies in Power Automate's robust standard connectors for core Microsoft 365 services, which include Outlook and SharePoint.  

The Outlook connector provides the "When a new email arrives (V3)" trigger, a standard action that allows Power Automate to monitor a specified email inbox for incoming messages. This trigger will be configured to detect the automated Jira reports.  

For the destination, standard actions within the SharePoint connector, such as "Create item" and "Update item" for SharePoint Lists, or "Create file" and "Update file" for SharePoint Document Libraries, are available in the free tier. The user's request to "update in a sheet" could imply either a SharePoint List or an Excel file stored in a SharePoint Document Library. However, for simplicity and adherence to the "minimal things" principle, a SharePoint List is the most effective and straightforward destination. This choice is based on the direct item manipulation capabilities offered by SharePoint Lists, which contrasts with the complexities of updating Excel files without premium connectors.  

A key technical challenge in this solution is the parsing of the HTML table. Since Jira filter subscriptions deliver data as HTML tables within the email body , and Power Automate's standard connectors do not include a direct "Parse HTML Table" action (a feature often found in premium or third-party connectors), extracting the data requires manual string manipulation. This involves using Power Automate's built-in expressions and "Compose" actions. This process typically includes steps like converting HTML to text, splitting the text by line breaks and specific delimiters, and extracting values based on their position. This manual parsing introduces a critical point of fragility: any future changes to Jira's email template (e.g., a new HTML tag, a different table structure, or even subtle formatting shifts) could potentially disrupt the Power Automate flow. While the "easy peasy" ideal is desired, this step requires careful, precise formula construction and ongoing maintenance. Therefore, it is important to provide concrete examples and advise the user to monitor the flow for unexpected failures due to format changes.  

Furthermore, the choice of SharePoint destination is crucial. While the phrase "update in a sheet" might suggest an Excel file, a SharePoint List is demonstrably the more viable and simpler destination for a "minimal" and "easy peasy" solution within the free tier. The SharePoint connector offers straightforward "Create item" and "Update item" actions for lists. These actions directly map parsed data to list columns, simplifying the process. In contrast, while Power Automate can interact with Excel files, the Excel Online (Business) connector, which provides row-level update capabilities, is typically a premium connector. Manipulating Excel files for row updates in the free tier would be significantly more complex, often requiring the creation of a blank file, defining a table, and then adding rows, which might still encounter premium action limitations or introduce file locking issues. Therefore, explicitly recommending a SharePoint List guides the user towards the most achievable solution, avoiding the problematic path of direct Excel row updates with free connectors.  

Step-by-Step Implementation Guide

Implementing this automation involves two main phases: configuring Jira to send the necessary data and building the Power Automate flow to process and update SharePoint.

Phase 1: Configure Jira for Automated Email Reports

The first step involves setting up Jira to regularly send the "ready for deployment cards" via email.

• Crafting the JQL for "Ready for Deployment" Cards The initial and most crucial step is to precisely define the set of Jira issues intended for tracking. Jira Query Language (JQL) serves as the powerful search syntax for filtering issues based on various criteria. For "ready for deployment cards," a JQL query that accurately captures these specific issues is essential. A common starting point for such a query would be:  

  project = "YourProjectKey" AND status = "Ready for Deployment" ORDER BY updated DESC. In this query,  

  "YourProjectKey" should be replaced with the actual key of the Jira project (e.g., "DEV," "PROJ"). The status = "Ready for Deployment" clause specifically targets issues that have reached this particular status. Including ORDER BY updated DESC is a beneficial practice as it ensures that the most recently updated issues appear first in the report, which can be particularly useful for deployment calls. This JQL can be further refined to incorporate other relevant criteria such as issuetype, assignee, labels, or fixVersion, depending on specific needs. It is important to note that while Jira's REST API requires JQL queries to be URL-encoded when used directly as a request parameter , for Jira's internal filter subscriptions, the JQL is typically input directly into the filter configuration, and Jira handles the internal processing.  

• Setting Up a Scheduled Jira Filter Subscription to Email (HTML Format) Once the JQL query is defined, the next steps involve configuring Jira to send automated email reports.

  1. Save the JQL as a Filter: Within the Jira instance, navigate to the "Issues" section. Enter the crafted JQL query (e.g., status = "Ready for Deployment") into the search bar and execute the search. Once the results are displayed, click the "Save as" button to save this query as a reusable filter. It is advisable to give it a clear and descriptive name, such as "Ready for Deployment Cards Report."  

  2. Create a New Subscription: Access the saved filter's "Details" or navigate to the "Manage Filters" section. Locate the "Ready for Deployment Cards Report" filter and find the option to create a "New Subscription".  

  3. Configure Schedule: Within the subscription settings, define the desired frequency and time for the email to be sent. For instance, if deployment calls occur daily, the subscription can be set to run "Daily" at a time that ensures the data is fresh and available before the call.  

  4. Specify Recipient: Enter the email address that the Power Automate flow will monitor. For automation purposes, using a dedicated mailbox is recommended, though a personal email address can be used if it is the sole recipient and the data volume is low.

  5. Content Format: Confirm that the subscription is configured to send the results as an HTML table embedded within the email body. This is the default format for Jira filter subscriptions and is the format Power Automate will be designed to parse.  

     The Jira filter subscription operates under the permissions of the user account that created it. It is crucial to ensure that this user account possesses the necessary "Browse Issues" and other relevant permissions to view all the issues that the JQL query is designed to retrieve. No separate API token configuration is typically required for the subscription itself, as it functions as an internal Jira mechanism.  

• Table: Example JQL Queries for "Ready for Deployment" Statuses This table serves as a practical, ready-to-use resource, directly addressing the need for "ready for deployment cards." It simplifies the initial setup phase by providing concrete JQL examples, making the process more straightforward and reducing the learning curve for JQL syntax.

JQL Query	Description
status = "Ready for Deployment" AND type = "Story"	All stories currently in "Ready for Deployment" status.
project = "PROJ" AND status in ("Ready for UAT", "Ready for Prod") AND assignee is EMPTY	Issues in UAT or Production status without an assigned individual in Project PROJ.
issuetype = Bug AND status = "Resolved" AND resolutiondate >= "-7d"	Bugs that have been resolved within the last 7 days (this can be adapted to an equivalent "Ready for Deployment" status).

Export to Sheets

Phase 2: Build Your Power Automate Cloud Flow

This phase outlines the construction of the Power Automate flow that will receive the Jira email and update the SharePoint sheet.

• Trigger: "When a New Email Arrives (V3)" (Outlook Connector) To initiate the automation, an "Automated cloud flow" must be created in Power Automate. The trigger for this flow will be "When a new email arrives (V3)" from the Office 365 Outlook connector. It is essential to configure this trigger to respond only to emails originating from Jira (e.g.,  

  jira@yourcompany.atlassian.net) and possessing a specific subject line (e.g., [Jira] Subscription: Ready for Deployment Cards). This filtering mechanism is critical for flow efficiency, preventing the processing of irrelevant emails and conserving the limited runs and API requests available in the free tier.  

• Action: Extracting Data from the Email's HTML Table (Using Compose and String Functions) The most intricate part of this free-tier solution involves extracting data from the HTML table embedded in the Jira email, as Jira sends HTML tables rather than direct CSV attachments. Power Automate's free tier necessitates manual parsing of this HTML content. The process typically involves a series of "Compose" actions combined with string manipulation functions.  

  1. Compose - Get HTML Body: Begin by using a "Compose" action to retrieve the Body content from the incoming email trigger's output.

  2. Compose - Isolate Table (if needed): If the email body contains additional HTML content beyond the table, use split() and concat() functions to precisely isolate the <table>...</table> section. An example expression could be: concat('<table ',first(split(last(split(triggerOutputs()?['body/body'],'<table ')),'</table>')),'</table>'). This step is vital for ensuring robust parsing and preventing unintended data extraction.  

  3. Compose - Convert HTML to Text/Clean: Convert the isolated HTML table into plain text. This often requires replacing HTML tags (<td>, <tr>, <th>) with chosen delimiters (e.g., commas, semicolons, newlines) and then splitting the resulting text. This is frequently the most complex part of the flow and may require iterative refinement based on the exact HTML structure of Jira's email output. For example, a simplified expression might look like:  

     replace(replace(replace(outputs('IsolateTable'), '<tr>', '\n'), '<td>', ','), '</td>', '').

  4. Compose - Split into Rows: Split the cleaned text by the newline character to create an array where each element represents a row of data: split(outputs('CleanedHtml'), decodeUriComponent('%0A')).  

  5. Apply to Each - Process Rows: Implement an "Apply to each" loop to iterate through each row of the parsed data. If the first row contains headers, it can be skipped using an expression like  

     skip(outputs('SplitIntoRows'),1).  

  6. Compose - Split into Columns: Inside the "Apply to each" loop, split each row by the chosen delimiter (e.g., a comma) to obtain an array of individual column values: split(item(), ',').  

  7. Compose - Extract Specific Data: Extract the desired "card" fields (e.g., Issue Key, Summary, Status) by referencing their respective array indices (e.g., outputs('SplitIntoColumns') for the first column).  

• Action: Transforming Data for SharePoint (Using "Create CSV Table" or "Select" actions) Once the data is extracted, it needs to be prepared for the SharePoint destination.

  • Option 1: Create CSV Table (for SharePoint Document Library) If the ultimate goal is to create a CSV file within a SharePoint Document Library, the "Create CSV table" action can convert the structured JSON array (derived from the parsed HTML data) into a CSV string. This is a suitable approach if the "SharePoint sheet" refers to a file that will be uploaded to a document library.  

  • Option 2: Select (for SharePoint List) If targeting a SharePoint List, which is the recommended approach for its simplicity, the "Select" action (found under Data Operations) should be used. This action transforms the extracted data into a structured JSON array that is suitable for mapping to SharePoint list items. It allows for renaming fields and ensuring that data types align correctly before the update operation in SharePoint. For example,  

    Issue Key from Jira could be mapped to the Title column in the SharePoint list, Summary to Description, and Status to a custom column like JiraStatus.

• Action: Updating the SharePoint Sheet (Using "Update Item" or "Create Item" actions from SharePoint Connector) This is the final step where the parsed and transformed Jira data is written to SharePoint. The SharePoint List is the recommended destination for its straightforward "easy peasy" integration [Insight 3].

  1. Get Items (Optional, for Update): If the intention is to update existing items in SharePoint rather than always creating new ones, a "Get items" action from the SharePoint connector is necessary. This action retrieves existing SharePoint items to find a match (e.g., by comparing the Jira Issue Key with a corresponding column in SharePoint).  

  2. Conditional Logic (for Update/Create): A "Condition" control should be used to evaluate whether a matching item already exists in SharePoint. This decision typically hinges on whether the "Get items" action returned any results.

  3. Update Item: If a match is found, the "Update item" action from the SharePoint connector is used to modify the existing SharePoint list item. This requires the SharePoint List ID and the unique ID of the item to be updated, with the parsed Jira data mapped to the relevant SharePoint list columns.  

  4. Create Item: If no matching item is found (indicating a new Jira card), the "Create item" action from the SharePoint connector is used to add a new entry to the target SharePoint list.  

     It is important to reiterate that while the user mentioned "update in a sheet," directly updating an Excel file in a SharePoint Document Library with parsed data is highly problematic and likely impossible with standard connectors for row-level updates, given the "no paid version" constraint. The Excel Online (Business) connector, which provides row-level update capabilities, is typically a premium connector. Although Power Automate can create new Excel files or tables , and actions like "Add a row into a table" and "Update a row" exist , these are generally associated with premium licensing. Therefore, the user should be guided towards utilizing a SharePoint List as the destination.  

• Table: Power Automate Flow Steps Overview (Standard Actions) This table provides a concise summary of the Power Automate actions involved, their purpose, and key considerations for operating within the free tier. It reinforces the "easy peasy" aspect by presenting a clear, sequential flow. The clarity of this table helps a Practical Project Coordinator understand the process and confirms the use of standard actions, aligning with the "no paid version" constraint.

Step	Connector	Purpose	Key Configuration / Considerations
Trigger: When a new email arrives (V3)	Office 365 Outlook	Initiates the flow upon receiving the Jira report email.	Filter by sender (Jira email address) and a specific subject line to avoid irrelevant triggers.
Compose (Get HTML Body)	Data Operations	Extracts the full HTML content of the email body.	Uses the Body output from the email trigger.
Compose (Isolate HTML Table)	Data Operations	Extracts the specific HTML table section from the email body.	Employs concat() and split() expressions to target <table>...</table> tags.
Compose (Clean HTML/Split Rows)	Data Operations	Converts the HTML table to plain text and splits it into individual rows.	Uses replace() to remove HTML tags and split() by newline character (decodeUriComponent('%0A')).
Apply to each	Control	Iterates through each row of the parsed Jira data.	Loops through the output of the "Split Rows" step; use skip() to bypass header row if present.
Compose (Split Columns)	Data Operations	Breaks down each row into its individual data points (columns).	Uses split() by the chosen delimiter (e.g., comma) within the loop.
Select (Transform Data)	Data Operations	Maps the extracted data to the desired SharePoint list column names.	Creates a JSON array of objects with properties corresponding to SharePoint columns.
Get items (Optional, for Update)	SharePoint	Checks if the Jira item (e.g., by Issue Key) already exists in the SharePoint List.	Filters SharePoint list items based on a unique identifier like Jira Issue Key.
Condition	Control	Determines whether to update an existing SharePoint item or create a new one.	Evaluates if the "Get items" action returned any results (i.e., if a match was found).
Update item (If item exists)	SharePoint	Modifies an existing item in the SharePoint list.	Requires the SharePoint List Name, the ID of the existing item, and mapping of parsed fields.
Create item (If item new)	SharePoint	Adds a new item to the SharePoint list.	Requires the SharePoint List Name and mapping of parsed fields to new item properties.

Export to Sheets

Authentication and Permissions: Minimal Setup

Proper authentication and permissions are essential for the seamless operation of this automation, even with a "minimal" setup.

• Jira API Token for Email Subscription (if required by Jira setup) For Jira's internal filter subscriptions, the authentication is inherently tied to the user account that creates the subscription. It is crucial to ensure that this user possesses the necessary permissions to view all the issues included in the JQL query. While direct API calls from Power Automate (which would typically require an API token ) are not part of this free-tier solution, the underlying Jira user's permissions are paramount for the subscription to function correctly.  

• Power Automate Connections to Outlook and SharePoint The Power Automate flow will require established connections to the user's Office 365 Outlook and SharePoint accounts. These are standard connectors and typically authenticate using the user's Microsoft 365 credentials. It is imperative that the account used for the Power Automate connection has appropriate access: read access to the email inbox designated for receiving Jira reports, and read/write access to the target SharePoint List. While a more complex solution involving custom HTTP requests to SharePoint (e.g., for intricate file uploads) might necessitate Azure AD app registration with specific SharePoint API permissions (such as  

  Sites.FullControl.All or Sites.ReadWrite.All) , such advanced configurations are beyond the scope of this "minimal" and "easy peasy" solution.  

A key security consideration, even though direct API calls are avoided for the free tier, pertains to Jira API tokens. These tokens are designed to be more secure than using passwords directly and offer the flexibility of individual revocation. While the current solution relies on Jira's email subscription mechanism (which implicitly uses the creating user's permissions), it is generally good practice to treat any API tokens, if used in other contexts, with the same level of security as passwords. This means safeguarding them and revoking them if compromised. For the chosen solution, the security primarily depends on the robust security of the email account receiving the Jira reports and the integrity of the Power Automate connection itself.  

Important Considerations for a "Minimal" and "Easy Peasy" Setup

While this free-tier solution offers a practical approach, it is important to acknowledge certain limitations and best practices to ensure its reliability and maintainability.

• Power Automate Free Tier Limitations (Run Frequency, API Request Limits) Operating within the free tier of Power Automate means adhering to specific operational limits. Free plans typically have a monthly run limit of approximately 750 flows and a minimum recurrence interval of 60 seconds. For a "daily" deployment call, a flow scheduled to run once a day is well within these limits. However, it is crucial to be mindful of API request limits; the free plan imposes a daily limit of 6,000 API requests. Each action executed within a Power Automate flow counts as an API request. While the "few cards" approach should generally remain below this threshold, a significant increase in data volume or a shift to very frequent runs could quickly exhaust this daily limit. Furthermore, Power Automate flows can be automatically turned off if they consistently fail or are subjected to throttling for a period of 14 days. This emphasizes the importance of robust error handling and proactive monitoring.  

• Handling Data Volume and Complexity (Keeping it to "Few Cards") The effectiveness of this solution is closely tied to the volume and consistency of the data. The reliance on string manipulation for parsing HTML introduces a notable fragility: any minor change in Jira's email template (e.g., the introduction of a new div tag, a different class name, or even subtle formatting shifts like extra spaces) could potentially break the Power Automate flow. This represents a significant hidden risk for a "minimal" solution. Therefore, it is essential to ensure that the columns extracted from the HTML table precisely match the expected SharePoint list columns; any mismatch will lead to errors. It is also worth noting that Jira's "Lookup issues" smart value, used in some automation rules, only returns the first 100 issues. While email subscriptions can export larger datasets (sometimes in batches, as seen with Python scripts ), large datasets can still pose challenges for Jira's native automation features and potentially for the size of the email content itself.  

• Basic Error Handling and Monitoring Given the inherent fragility of HTML parsing, proactive monitoring is not merely a best practice but a necessity for this free-tier solution. Without it, the flow could silently fail, resulting in outdated deployment data in SharePoint. Power Automate provides a detailed run history feature that allows users to monitor flow executions and identify any errors. It is advisable to configure an additional "Send an email" action within the flow to notify the user if the flow encounters a failure, including relevant error details. While complex data validation is beyond the scope of an "easy peasy" setup, ensuring that the parsed data types align with the SharePoint column types is important. Power Automate also includes default retry policies for actions that experience temporary failures.  

This reliance on string manipulation for HTML parsing means that any minor change in Jira's email template (e.g., a new div tag, a different class name, or even extra spaces) could disrupt the Power Automate flow. This is a significant inherent risk for a "minimal" solution. Therefore, regular monitoring of the flow's run history is crucial , and users should be prepared to adjust the parsing logic if Jira's email format changes. If reliability becomes paramount and the data structure is prone to volatility, a more robust (but potentially paid) solution should be considered.  

Furthermore, the clear limits on runs and API requests in the free tier mean that while the "few cards" approach is acceptable, if the user's needs expand (e.g., more cards, more frequent updates, or more complex data), these limits will inevitably be reached. The fact that the Excel Online connector for row-level updates is often a premium feature further indicates a push towards paid tiers for increased functionality. This information helps manage expectations regarding scalability, positioning the current solution as a valuable starting point for minimal needs while acknowledging that enterprise-level or growing requirements will likely necessitate a paid Power Automate license (which enables premium connectors like Jira and more robust Excel actions) or a third-party ETL tool. This provides a clear upgrade path and justifies the focus on the free tier for initial implementation.  

Recommendations for Ongoing Use and Future Enhancements

To ensure the continued effectiveness and potential growth of this automation, several recommendations are provided:

• Regular Monitoring: Periodically check the Power Automate flow's run history for any failures or performance issues. It is highly advisable to set up automated email notifications to alert the user immediately if the flow encounters a failure, including relevant error details for quicker troubleshooting.  

• Jira Filter Maintenance: Regularly review and update the Jira JQL filter to ensure it accurately captures the "ready for deployment" cards as project workflows and definitions evolve over time.

• SharePoint List Structure: Maintain a consistent structure for the target SharePoint list. Avoid making manual changes to column names or types that the Power Automate flow relies on, as this could break the data mapping.

• Consider a Dedicated Jira User: For enhanced security and improved auditability, it is recommended to create a specific Jira user account with minimal, necessary permissions solely for the purpose of generating these automated reports. This separates the automation's activities from individual user accounts.  

• Future Enhancements (Considering Paid Options): As needs evolve, or if the limitations of the free tier become prohibitive, several upgrade paths can be explored:

  • Power Automate Premium Connector for Jira: If the manual HTML parsing proves too fragile, or if data volume and frequency increase beyond free-tier limits, investing in a Power Automate Premium license would enable direct integration with Jira. This offers more robust data retrieval, advanced filtering, and direct update capabilities, eliminating the need for email-based workarounds.  

  • Third-Party Integration Tools: For more sophisticated data synchronization, real-time updates, and advanced error handling, dedicated Jira-SharePoint integration tools or ETL (Extract, Transform, Load) platforms (e.g., Skyvia, adenin) can be explored. These solutions typically come with licensing costs but offer greater reliability, scalability, and a richer feature set.  

  • Custom Scripting (Python/PowerShell): For highly customized or large-scale exports and transfers, developing a custom Python or PowerShell script can be an option. Such a script could directly pull data from Jira's REST API and upload it to SharePoint via its APIs. This approach offers maximum flexibility but requires development, hosting, and ongoing maintenance, adding to operational complexity and cost.  

The importance of proactive monitoring for solutions that rely on indirect data extraction, such as HTML parsing, cannot be overstated. Given the inherent fragility of this method, proactive monitoring is not just a best practice but a fundamental necessity. Without consistent checks, the flow could silently fail, leading to outdated deployment data. The emphasis on logging and monitoring for automated data transfers highlights that "easy peasy" does not equate to "set and forget." Regular checks and failure notifications are critical to ensure the solution remains functional and accurate.  

Furthermore, by outlining the benefits of paid alternatives (Power Automate premium, third-party tools, custom scripting), the report provides a clear justification for why a user might eventually need to move beyond the free tier. This frames the current solution as a valuable starting point while acknowledging its inherent limitations. This approach helps the Practical Project Coordinator understand the trade-offs between cost and functionality, enabling informed decisions for future needs and positioning the current solution as a strategic initial step.

Conclusion

The outlined Power Automate flow provides a viable and cost-free solution for automating the updates of Jira "ready for deployment" cards to a SharePoint list. This approach effectively navigates the constraint of avoiding paid Power Automate versions by leveraging Jira's native email subscriptions and Power Automate's standard Outlook and SharePoint connectors.

It is important to recognize the balance between a "minimal" setup and the inherent limitations of free-tier services, particularly concerning the fragility of HTML parsing and the scalability of API requests. While this solution is highly effective for managing a small volume of "easy peasy" data, users should be prepared for potential adjustments if Jira's email format changes and understand that significant increases in data volume or update frequency may necessitate an upgrade to premium services or more robust, custom-coded integrations.

This report encourages users to implement this initial solution to gain immediate value in streamlining their deployment tracking. As organizational needs evolve and grow, the insights provided on scalability and alternative tools will serve as a valuable guide for considering more comprehensive and robust automation options.

[Valerie Knapp]

Hi @Aslam Mohammed , thanks for your post. 

What are you trying to achieve exactly? When an issue is created in Jira, what did you want to happen on the Microsoft side? 

Best wishes

[Aslam Mohammed]

Hi Valerie,

We are trying to do the following:

"When a New issue is returned by the JQL we would like to Get All the Issues in the same Jira Project and write to a CSV File"

The action "Get list of issues" is not working as per the documentation as it doesn't have a Parameter or Settings to provide the JQL.