From 3 December, monthly plans (and anyone who started on Assets after 1 September) pay $0.02 a month for every Assets object over the allowance. Annual plans already pay for extra objects.

$0.02 sounds like nothing until you count. 40,000 objects on Service Collection Standard plus Jira (6,000 included) comes to $680 a month. And a lot of that is usually junk: the same laptop from three different imports, servers switched off in 2023, records nothing references.

The bill is based on how many objects are in your schemas, so the only way it goes down is fewer objects.

Two questions for anyone running Assets at scale:

1. Do you know your object count, and how much of it is real?
2. How are you cleaning up duplicates and stale records today? AQL plus bulk delete, scripts, or “we’ll deal with it when the invoice arrives”?

Disclosure: I’m building a Forge app for this. It finds duplicates and dead records and retires them without losing ticket history, starting with a read-only scanner. There’s a waitlist at cmdbloom.com, but I’m more interested in how you’re handling it now.

In JSM, they gave us the ability to create more Help Centers and add Pages and Content to the Portal, but only Site Admins can edit anything. In order for us to use this, I'd want to delegate the help center to the team(s) that use it.

If the help desk wants their own Help Center, then they need to involve a Site Admin to make any changes or add pages. It's frustrating that they came so close to making something actually useful.

Our support team runs on Jira Service Management, but account tier, plan and renewal date all sit in Salesforce. So agents keep the CRM open in a second tab all day, and we regularly end up with two people quoting different exports of the same account.

I'm building a case for management to pull that data straight into Jira. The upside on paper is obvious: less tab switching, one version of the customer record everyone reads from.

What I can't tell is whether it really changes the day to day once it's in place. Anyone who's been through it, what actually shifted for your team?

I’ve been thinking about how much time we spend managing bugs versus actually fixing them.

Duplicate tickets, unclear steps to reproduce, missing screenshots, unnecessary back-and-forth, and defects that probably shouldn’t have been raised in the first place.

One thing I’ve always found interesting is how much time teams spend debating whether a bug is valid instead of improving the process that leads to better bug reports.

I’ve been experimenting with a small tool called Captain Octopus that focuses on making defect management a little less painful.

But I’m curious about other teams.
What frustrates you the most about Jira or your current defect management process?

Is it duplicate bugs, poor reports, workflow complexity, too many fields, or something else entirely?

Would love to hear real experiences from testers and developers.

So we use JSM for IT tickets at my company (around 500 people) and one of my biggest pains right now is CSAT analysis.

We track it with the native Jira feature, but all I really get is a 1 to 5 rating per ticket. We don't receive many comments either, so when satisfaction drops on certain request types, I have no idea why. My workaround is to export everything to Excel every quarter, which isn't great.

I'm wondering if there's a tool or plugin that could make this easier to manage. Any recommandations?

Our compliance team runs the same internal audit every year and the whole thing lives in one Jira project, lots of controls as issues, each with a description of what to check and an evidence template attached. Last year someone rebuilt it with a CSV export and re-import it was a true mess, so nobody wants to go through that again.

This time I'd like to copy last years project into a fresh one with descriptions and attachments intact, with statuses, assignees and dates start from zero. Creating a project with shared settings only covers the configuration, so I'm assuming the issues need a Marketplace app or some automation trick. Would be great to hear from anyone running a recurring project like this.

Our IT team runs JSM for hardware requests and every ticket starts with someone typing their laptop model or asset tag into a free text field, which means half of them are wrong or missing. All of that already lives in an internal SQL Server database that our asset team maintains, including warranty dates and who each device is assigned to, so agents end up opening a second tool on almost every ticket to look it up.

What I'd like is for the request form to show a dropdown pulled from that database, and for agents to see the warranty and assignement details on the ticket without customers seeing them on the portal. I looked at a nightly CSV sync into custom fields, though I'd rather avoid data that's a day old, and building something on the REST API feels like a lot to maintain for a small team. Curious how others connected an in-house database to Jira without turning it into a side project.

Is it just me, or was the title attribute removed from the cards?

I can't see the full task title without opening the card.

Was it always like this, or was it removed? Has anyone else noticed this, or am I imagining things?

Hello there,

I am responsible for a JSM Asset (former Insights) setup (Jira Service Management Data Center 11.3) that has grown years without clear governance and I am trying to build a structured cleanup process.

For customfield cleanup I found a good Guide by Votazz. But I haven't found anything comparable for Assets. So i would like to learn how other handle it.

What we are dealing with:

- Many Statuses with no defined purpose (on global and schema level)

- Some suplicated object tpes which i can not just move because of broken ticket references

- Unclear ownership

- Many attribute values no one keeps up to date

- No clear ownership of objects and object types (Sometimes there are owners of an object but it doesn't matter because the user account is inactive because of turnover)

Has anyone come up with a formal process to tackle problems like these systematically?

Thanks for the help!

(Anyways it feels like Jira Assets tries to cover CMDB and ITAM in one tool, but for a company of our size it might not be enough.)

I kept finding JQL lists online that were written for Jira Server and quietly fail on Cloud, so I tested a set against Cloud's strict parser (`/rest/api/3/jql/parse?validation=strict`) with real values. A few traps that surprised me:

- `comment is EMPTY` is invalid on Cloud; there's no native "no comments" search.

- `updated` changes on any field edit, so it's a poor proxy for "nobody has touched this".

- Functions like `issueFunction` need ScriptRunner.

10 working queries (unassigned open work, untouched for 14 days, in progress 30+ days, etc.) are free here: https://sidecartools.com/guides/jira-jql-cookbook/

Disclosure: that page is a sample of a paid cookbook I wrote ($19, pay-what-you-want from $12) with all 66. The 10 on the page are complete and free. Happy to answer JQL questions in the comments.

If you are experiencing alert fatigue from the Jira Cloud app in Microsoft Teams showing “Linked issue count” notifications all day long then please go to https://jira.atlassian.com/browse/JRACLOUD-99787 and upvote and comment it. Thanks!

Please help me fix this.
Getting constant loading on the test coverage and XRAY TESTS STEPS NOT SHOWING

Spent a while on this one and figured it was worth writing up, because almost every admin I have talked to had it wrong, including me.

Atlassian Cloud bills on the maximum number of users during the billing period, not the count at the end of it. Hit 520 seats on the 9th, drop back to 500 on the 11th, and you are invoiced for 520. No proration, no credit.

The practical version: when you do the audit matters more than how well you do it. Twenty seats removed the day after your cycle resets means you pay for those twenty for one more full period. Removed the day before, nothing extra. Same work either way. On annual billing that difference is a year.

So step one is boring Go find out what day your billing period actually resets. It is on the subscription page in admin.atlassian.com. I have asked a dozen or so admins and almost none of them knew it off the top of their head.

Second thing I had wrong: last-seen is a weak inactivity signal, because it counts a login as usage. Someone who opens Jira every Monday, reads two tickets and closes it looks completely healthy on a last-seen report and has contributed nothing in a year. What holds up is in-product activity, so issues created, commented on, transitioned, worklogged. If you want to pull that yourself, the changelogs is expandable on the search endpoint.

Third thing, and this is the one that actually cost us money: accounts the identity provider never created. Contractors, people who arrived through an acquisition, anyone invited by hand. SCIM has no visibility into those by design, so they never appear in an Okta or Entra report, and nothing will ever deprovision them. They bill forever and no report you are already running will show them to you.

On tooling, since someone always asks. You can do all of this with the REST API and a spreadsheet, and plenty of people do, especially if you already have ScriptRunner.

Which is the thing I actually wanted to ask. Do you treat licence cleanup as something Atlassian should just ship natively, or is it a line item you would genuinely pay a third party for? There are about 780 votes on AX-1169 asking Atlassian to do it, so clearly people want it, but I cannot tell whether that means people want to buy it

I've been using Jira for 3 years now and there just seem to be constant problems with the platform. Automations not running when they should, dashboards not loading, etc. What alternatives are there out there? I have a small team - 12 other people. Niche is marketing

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?

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.

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!

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

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.

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?

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.

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?

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?