Hi Wendy, What is it you want to achieve? For example, (1) do you want separate work items (eg. sub-tasks) so that you can split out the work done by the different teams involved in the process? Or (2) do you want to capture metrics on things like "flow efficiency" so that you can see how much time is spent doing work and how much time is spent waiting - this kind of data can be used with senior management to help drive process changes when you can see where the delays are coming from. If (1) then I think your use of sub-tasks is the way to go. If (2) then your workflow status names already have the foundations to start collecting metrics to determine your flow efficiency, eg. Active States - In Progress - In Review - In QA - In UAT Waiting States - Backlog - To Do - Ready for QA - Ready for UAT - Ready for Prod If you have add-ons like Custom Charts it can generate the metrics for you easily. If you don't, then you could do it via Jira automations - although some set-up is needed! Once you have the data, it should help to show where your biggest hold-ups are to help start conversations about what process and/or Jira config changes could help to reduce the waiting. Similarly, you can bring in Cycle Time and Lead Time in to the same data set to get an indication of how much time your build/dev efforts are taking (cycle time) compared to how much time to get the change shipped to the customer (lead time). I suspect your lead times are excessive compared to your cycle times - that kind of data can help drive conversations about changes are needed to reduce the time to ship product to customers. Overall, I think there's only so much Jira can do for you - it sounds more like changes to your resourcing and/or process are needed, but the data from Jira may help drive that. For example, if your delays are from waiting for your QA cycles to complete, can you change your process to ship as a "beta" release to selected customers in production who do the testing for you? Atlassian do it all the time - but don't get me started on what I think about that! :)

Hi - have you looked at the out-of-the-box reports on your premium plan? They're not the best, but they're free! - Velocity report - Burnup report - Sprint burndown chart - Cumulative flow diagram - Cycle Time Report - Deployment Frequency Report The newish Summary view on Jira boards has some useful data widgets for high-level reporting, but you can't customise much in them unfortunately. You'll also be able to do a certain level of reporting with Jira dashboards without using any add-ons like Custom Charts - but you will get to a brick wall at some point depending on how complex your reporting is! You can also have your Jira data pulled into Excel/Google sheets via real-time links, and once you've got your data in them then you'll have the full capability of Excel/Google to manipulate and chart your Jira data - all at no additional cost.

I would echo what a few others have also said - try to make your custom fields re-usable as much as possible to avoid bloating your config with lots of similar fields. If you need additional variations for that field, have a secondary (re-usable) field that can be used for that purpose. For example, - name your primary field "Address" so that it is generic and re-usable - have a secondary list field called something like "Address Type", with list values such as "Physical address", "Mailing address", etc. When using a secondary field, then try to make that generic and re-usable also if possible. For example, call it "Type" instead of "Address Type" and use a field context to set the required list of values (Physical, Mailing). This allows the "Type" field to also be used in different spaces with different lists to cater for different use-cases (address type, car type, house type, etc). If the intention of the secondary field is not clear to an end-user when added to a screen, then you could possibly add a "Guidance" field that is configured as message field to provide some static text on the screen to explain the purpose of the Type field (eg. "Select the type of address from the Type field"). If you put this static text in the field context then that then also becomes re-usable for different use-cases (eg. "select the address type..", "select the car type...", "select the house type...", etc! This might be getting complicated now! But the principle is if you name your fields carefully then this kind 3-level approach allows those 3 fields to serve many use cases to avoid you creating separate fields for each use-case. However you'll need to find a good balance between both methods.

Hi - does your organization have Slack AI as part of your Slack license/subscription? If so, then you can do this via Slack AI directly without needing to store anything in Confluence. Slack AI has a feature to summarise a thread or an entire channel from the past 7 days or over a custom date range.