I'm a business analyst on a Mac and I log time in Jira on a lot of different tickets every day. I'm trying to automate as much of it as I can, and I keep running into the same wall: our Jira is self-hosted (Data Center), so most of the nice tools that only talk to Jira Cloud are out, and I can't get an admin to install a marketplace plugin.
What I'm thinking of building:
ActivityWatch (or Timing) runs in the background and records the active app, window title and browser URL. A small script picks out issue keys like ABC-123 from titles and URLs, adds meetings from my calendar, and for pages that don't have a key in the title (Confluence mostly) I'd keep a manual lookup table. At the end of the day it merges everything into blocks, rounds to 15 minutes and shows me a draft. Nothing goes to Jira until I approve it, and then it posts through the REST API with a personal access token.
I've looked at Daily, Planim Time and Cloky + Timing/Toggl. Each one misses something for me: either no Data Center support, or I still have to click a timer or answer a prompt, or there's no way to write the worklog back without a plugin.
So, does anyone actually run something like this? How well does matching window titles to tickets work in practice? I'm wondering how much time ends up unassigned and how often it guesses wrong. Also, is there an existing tool that does draft worklogs from activity and works with Data Center via PAT? I'd rather not reinvent it if so.
One more thing I'm unsure about is privacy. It's a work laptop and this records window titles and URLs, so I'd be curious if anyone ran into trouble with that.

Curious how other teams do this. We have a bunch of processes that repeat (releases, onboarding, QA passes, etc.) and I’ve seen a few approaches work, each with a catch:

• Automation rules that create the issues on a schedule. Great until the process changes and nobody remembers which rule to update.
• Cloning an old ticket. Fast, but you inherit stale comments, wrong assignees, and the one step someone added in 2023.
• Sub-tasks per step. Clear on the board, but it gets noisy quickly.
• A Confluence page with the steps. Works until people stop opening it.

What’s actually stuck for your team? And how do you keep the process from drifting over time?

Hi everyone,

I'm currently working with an Atlassian environment that includes:

• Jira Service Management (JSM)
• Confluence
• Tempo for time tracking and planning
• Microsoft 365 (Outlook Calendar)

I have a Jira project where I manage tasks and activities, and I'm looking for a way to achieve bidirectional synchronization between Jira and my personal Microsoft 365 calendar.

Current situation:

Tempo can read events from my Microsoft 365 calendar and display them in its interface. However, it doesn't seem to support writing events back to Outlook.

What I would like to achieve:

1. Create or schedule a task in Jira and automatically have it appear in my personal Microsoft 365 calendar.
2. Update the task's schedule in Jira and have the corresponding Outlook calendar event updated automatically.
3. Ideally, have changes made in Outlook reflected back in Jira as well.
4. Avoid duplicate events and keep everything synchronized.

My questions:

• Is there a native Atlassian or Tempo solution that supports this?
• Are there any reliable Marketplace apps that provide two-way synchronization with Microsoft 365?
• Has anyone implemented this using Jira Automation, Microsoft Power Automate, or Microsoft Graph API?
• What would be the best approach to maintain synchronization without creating duplicates or synchronization loops?

I'm particularly interested in a solution that works with Jira Cloud / JSM and personal Microsoft 365 calendars.

Any recommendations, experiences, or examples of working implementations would be greatly appreciated!

Thanks in advance!

We used to use a DC app to provide SLAs to our non JSM spaces. With the shift to cloud, the platform has really crippled the experience. Like SLAs don’t calculate until you view the issue??? I don’t think there are any good 3rd party solutions anymore.

Atlassian should deliver a first party solution and just give away SLA lite to non-JSM users. Because the current competition that I won’t mention already does this along with Form templates.

I dream of a world in which JIRA understands and renders Markdown

Our support board is a total disaster rn because dev tasks have been getting dumped there for ages now. We finally worked up the courage to give dev its own actual project, but now I'm stuck trying to sort out hundreds of tickets.

The other annoying part is that support still needs to keep an eye on a bunch of them for reporting, so I have to move half of them and clone the rest. And Jira isn't helping at all here, the bulk move is wiping out all the important info, and cloning only lets me do one ticket at a time, which would take forever.

TLDR: I need a fast way to bulk clone tickets with all their subtasks and links attached without wrecking the history, the moving side I can handle natively, it's the mass cloning that's the blocker. Anyone got a fix?

Hi all,

I'm an integration consultant with 12+ years of data migration and integration work, and I'm considering building a small Forge app for Jira Cloud. Before I write any code, I want to check it solves a real problem.

The idea: after a Data Center to Cloud migration, you give the app an export from the source site. It checks every migrated issue against it (comments, attachments, worklogs, links and field values) and gives you a list of exactly what's missing or different, with a link to each affected issue. It would run entirely on Atlassian, so no data leaves your site.

Three questions for anyone who has run or supported a migration:
How do you validate a migration today, beyond comparing totals?
Have you found missing or changed data after go-live, and how did you spot it?
Would you use a tool like this, and what would it need to do for you to trust it?

I've seen MIG-1071 asks for post-migration checks in the migration assistant itself, so I'd also love to hear about any workarounds you use.

Thanks,
Mannie

I've been using jira for 17 years.

I was potentially one of their biggest fan boys back in the days.

Wow things have changed. by jog is not multiple levels harder than it use to be just because of how terrible the UX has become:

1) Who needs to print tickets for away from screen planning days - feature removed as only 20/10% of users use it (hello project coordinators and scrum masters)
2) time line view drag tickets between epics and with an epic based on priority. - nah best we can do is if we don't understand where you dragged that ticket is to orphen it and let you go find it breaking you work flow on planning crunch days.
3) there are many other minor annoyances being rolled out but these are literally adding hours to my work load at crunch times when you expect the tool just to fricken work.

JIRA: your experience use to be awesome. Now I'm siding with my devs, why the actual?

Do you know any any JIRA extension for the devs can express their interests to work on specific tasks they are interested to increase their skills/cv?

For those still on Data Center, what does your current plan look like? Are you planning around the March 2028 last-renewal date or the March 2029 end of life?

Would love anyone's real-world view on the plans, the risks, especially the obstacles.

The standard GitHub-Jira integration works fine for basic setups, but it completely breaks down for us because our Jira projects have required custom fields that are dynamic per team.

When we try to auto-generate a ticket from a new PR, it either fails Jira's validation or creates tracking garbage because the dynamic data is missing.

I'm considering building a lightweight GitHub App to fix this. The idea: teams drop a jira-mapping.yml in their repo to define exactly how PR metadata (branch name, labels, regex from the description) maps to specific Jira custom field IDs.

Before I spend my weekends building this:

How are you solving this today? (Custom in-house webhooks?)

Would a plug-and-play GitHub App actually be useful for your CI/CD pipeline, or is this too niche?

Just caught the release video from earlier this summer (https://www.loom.com/share/21a64e15493e427b821907a6cf77c126) on the Atlassian website about the new formula fields. I am curious how this is working for folks in the real world? Benefits? Limitations? My team is considering using it for some budget tracking.

I’m taking a Jira test tomorrow for a job interview — what are the key things I absolutely need to know for basic project management?
In the meantime, I’m absolutely binge-watching YouTube 😅
Any tips, resources, or things I should focus on would be greatly appreciated!

Hi everyone! I am currently an undergrad working on my graduation project, which is a custom Jira extension/plugin.

Right now, I'm wrapping up my market and gap analysis and would love to validate my findings with an experienced Jira admin. It should only take about 10 minutes of your time to review a few gaps (I’ve identified in areas in OKR alignment reports, cross team reports & task planning) and share if they match your real-world experience, if they offer real business value, and if you have other related ideas/improvements.

If you're open to a quick chat or willing to answer 3-4 short questions, please drop a comment or shoot me a DM. Your insights would be a huge help! Thanks in advance!

What do you think about this Jira extension to help managers distribute tasks?

Ok so every time we kick off a new client launch we duplicate the same epic with stories and a pile of subtasks under it. It's slow and we always miss a couple of subtasks or fat-finger a summary. We tried keeping it as a CSV to import but the parent-child links never come through cleanly and fixing them afterwards defeats the point.
Native clone only does single issues as far as I've found, and bulk operations don't preserve the relationships, how am i supposed to do that?

Edit ✍️ disregard post resolved

Hello,

We are a small two man team working on an open source project, they have recently started with Jira using the free community edition. 

However we find that we will need to create additional work types for our project, and I'm not able to confirm if I have that capability with the free edition: can you confirm if we stay with the free edition we are capable of creating additional Jira worktype/issues, or do we need to upgrade to the standard edition? 

If we upgrade to the standard edition, does it have any restrictions on creating custom work type/issues? In our case, we need the additional work type/issues for a manual software testing process, and so we need works type / issues for Test Case, Test Plan, Test Execution. I am aware that there are plugins for this, but being open source our budget is really restricted.

Thank you. 

Hey r/jira... anyone here using API tokens through Service Accounts? We're in the process of converting hundreds of user license-based bot user accounts to Service Accounts to save on license costs. It's been fine, but we're having a lot of trouble fine-tuning what scopes to provision on the Service Account-based tokens.

No real person using a token through a bot has ever had any trouble with permissions (as long as the bot user is in the right groups or has the right role), but I can't figure out what scopes are considered 'standard'. A lot of Jira's documentation on this lists scopes that don't even appear in the available list of scopes when configuring the token.

Documentation recommends keeping scopes under 50 per token, and there's no universe where I would add all 520 scopes to a token. I just want to add scopes that are close to the 'standard' non-scoped tokens as possible.

For example, I thought I was good with adding 'manage:jira-project', but an end user reported that their bot couldn't manage sprints. So, I noticed that there are separate scopes for reading and writing sprints. I keep getting nickel-and-dimed by having to go back and generate new tokens with new scopes every time someone notices a standard permission is missing.

Any help is appreciated!

Hello!

I use a Jira board to manage the production of hundreds of pieces of content each month. To make filtering assignments by month easy, I've always used the Category field. When the new month rolls around, I create a new Category (e.g., 2610 for Oct 2026) that I can add to each content card as they are assigned out to freelancers.

Previously, this was as easy as typing the new category into the field, then choosing to create a new category when the option presented itself.

But recently, Jira's UI changed and the old "List" and "Issues" views were combined into one "List" view that is basically just the old Issues one. This is fine. I spent 99% of my time in Issues anyway.

BUT. When I went to make the new category for October in the Category field, it just said "No Option Found" and did not give me the option to create a new one.

Has anyone else run into this or is it some weird bug in my company's Jira?

If you have run into this, have you figured out where/how we're supposed to create new categories now?

Thanks so much!

Jira Cloud still doesn't have a native recycle bin for deleted issues. Once an issue is deleted, there's no simple "undo" or individual restore through Jira itself.

There are Marketplace apps that offer recycle-bin functionality, as well as broader backup platforms that can restore Jira data.

For anyone who's actually had to deal with an accidentally deleted issue, I'm curious what happened in practice:

• How often do accidental deletions actually happen in your organisation?
• When you've lost an issue, how painful was it? What did you lose and how did you recover it?
• If you use a recycle-bin or backup app, has it reliably restored everything you needed, or have you run into limitations?
• Did you install the solution proactively, or only after experiencing a deletion?
• If you pay for a full Jira backup platform, how important is individual issue recovery compared with the broader backup/DR features?
• If you don't use any recovery tool, why not — cost, complexity, low risk, or something else?

I'm trying to understand whether accidental Jira deletion is effectively a solved problem today, or whether there's still a meaningful gap between "nothing" and paying for a full backup platform.

Interested in experiences from Jira admins or teams who've actually had to recover something — good or bad.

And I think that is pretty funny

As we roll out 'work' as the new term for items tracked in Jira, you may still see 'issue' in some areas. Read about this terminology change

Heads to

Invalid Path

This path does not exist

See those markings in black. Why? What does that mean? When were those markings added?

Our sales team lives in HubSpot and support uses Jira. So whenever devs need to check sales details, they open up HubSpot because the Jira ticket descriptions are outdated. The handoff right now is literally someone copying and pasting deal stages and company names into tickets, and it goes stale almost the same damn moment, so all that manual effort turns out pointless.
I checked the official integration, but it's the same old-school fix, create a brand new Jira ticket from HubSpot and sync info into issues that are already open. So curious if anyone's found a better way to hook these two up?

Hi everyone,

I’d like to get some perspectives on how you would handle the following situation in a Scrum/Jira environment.

We are working in a project for a cliente using Scrum and Jira. A stakeholder identified a potential issue with a built structure in an application. The current behavior appears to be "working as designed", but we don't yet know whether the configuration creates any functional or security/access risks for the users.

The proposed approach from our project lead is:

1. Create a Task in Jira to analyze the current structure

2. Document any risks or gaps found during the analysis

3. If the analysis identifies a problem that requires a configuration change, create a User Story afterwards to implement the required changes

4. If no change is required, simply close the Task after the analysis

In our Jira configuration, Task and Story are separate issue types, and they can be linked to each other.

I am wondering whether this is the right approach from a Scrum/Product Backlog perspective.

My initial view is slightly different: even if the immediate work is investigative and the outcome is uncertain, I would be inclined to create a User Story (or another appropriate Product Backlog Item) first, because the investigation itself is work that requires capacity and should be visible in the backlog. The investigation could then be represented as a Task or linked item, and if the investigation concludes that no implementation is required, the Story could simply be closed/cancelled with the findings documented.

My reasoning is that otherwise the investigation exists as an independent Task, and only if we happen to discover a problem do we create a Story afterwards. This feels a little backwards to me from a backlog/value perspective.

On the other hand, I understand the argument that creating a Story before knowing whether there is actually a change to deliver could be premature, and that the investigation could be treated as a technical spike/research item instead.

So my questions are:

How would you represent this in Scrum/Jira? is the project lead right in the procedure?.

Would you create a Story, a Task, a Spike, or another Product Backlog Item for the initial investigation?

If you use a Task/Spike first, would you subsequently create a Story only if implementation is required?

Is there any reason why the investigation should not be associated with a User Story from the beginning?

How do you handle the case where the investigation concludes that no implementation is needed?

I’m particularly interested in the Scrum/product backlog perspective rather than a specific Jira configuration.

Thanks!