I’ve been messing around in our sandbox getting workflows, screens, and custom fields set up exactly how we want them, but now I’m stuck on the best way to actually migrate all of that over to prod without breaking anything or having to rebuild it from scratch by hand. Is there a built-in way to export/import project configs, or do most of you just recreate everything manually on the production side? Would really appreciate any tips, tools, or gotchas to watch out for from people who’ve done this before.

Hello!

I've been looking into ways to build a workflow that automatically attempts to solve reported bugs from Jira tickets.

I came across Jira's Claude AI agent, and I'm wondering if anyone here has actually used it for something similar. For example, taking a bug report from Jira, analyzing the issue/codebase(s), implementing a potential fix, and then creating a PR for human review.

Is Jira's built-in approach worth using for this, or would I be better off building my own custom workflow around Claude (or another coding agent)?

At the moment I'm leaning towards building the custom solution, mainly because it would give me more control over the workflow, but if Jira's solution is already capable of doing this well, I'd rather not reinvent the wheel.

Would love to hear from anyone who's tried this, especially in a real development workflow.

Thank you in advance.

GET /rest/api/user/viewissue/search

states that its limited "up to the 1000th user", given the startAt and maxResult parameters of 0 and 50. I would assume that given a projectKey only 1000 users are the maximum of possible result.

But when I paginate I can get up to the 1164 unique users. How is that possible?

I am trying to get a User <-> Project relationship going for our database.

Disclosure first: I build apps for the Atlassian Marketplace, including one in this area. There is no link or pitch in this post, and the method below is entirely native Jira automation with no app involved. Mods, remove it if that still crosses the line.

The problem

A rule that breaks loudly is the easy case. It errors, the owner gets an email, someone fixes it.

The hard case is the rule that stops running and nothing anywhere tells you. Four ways that happens:

1. Someone disabled it. Or Jira auto-disabled it after repeated failures and the notification went to a rule owner who left the company eighteen months ago.
2. The trigger stopped matching. A status got renamed, a field got replaced, a project moved to a different scheme. The rule is enabled and technically healthy. It just never fires.
3. It ran and did nothing. A JQL search inside the rule returned zero results, so no action was executed. Audit log entry: "No actions performed." Status: success.
4. Someone edited it. The change was sensible on its own and broke something three steps downstream.

Why the audit log can't catch this

The audit log records events. A rule that isn't running produces no events. You are looking for an absence, and absences don't write log lines.

I went through 277 complaints on Atlassian's public issue tracker while researching this, and the same shape kept coming back. One person described a rule that had worked for months, stopping with no audit log entry at all for the failed run. Another wrote that there is no warning and no error message, and no trace of the failure anywhere. A third objected that a rule which cannot guarantee a reliable result still gets marked successful. Someone else described clicking through fifteen pages of audit log to find a single failed run.

Worth noting separately: error notifications from automation go to the rule owner only. That is one of the most-voted open requests in that project.

The fix: watch for silence, not for failure

Every rule you care about checks in when it runs. A separate watchdog rule looks for check-ins that didn't arrive. A dead man's switch.

The build, all native

1. Create a dedicated project for heartbeats, call it HB. Lock the permissions down so nobody works in it.
2. On each rule you want to monitor, add a Create work item action as the last step. Write into HB with a unique label per rule: hb-nightly-sla, hb-escalation-ping, and so on.
3. Watchdog rule:
   • Scheduled trigger, JQL checkbox UNCHECKED
   • Lookup work items action, JQL: project = HB AND labels = hb-nightly-sla AND created > -90m
   • Condition: {{lookupIssues.size}} equals 0
   • Action: create an alert issue, or notify

The unchecked box matters. If you put the JQL on the scheduled trigger itself, the rule does nothing when the search returns nothing, which is exactly the case you are trying to detect. Using the Lookup action instead lets you test the empty result explicitly.

1. Cleanup rule: scheduled daily, JQL checkbox checked, project = HB AND created < -7d, delete.

Three things I got wrong on the way here

I first designed this with a JQL branch writing a datetime field onto a single fixed canary issue. In a business space, the branch would not execute at all. The audit log said "No actions performed" and gave no reason. The same field edits worked fine outside a branch. I never found the cause and gave up on branching. If anyone has a working branch-based version, I would like to see it.

Component names differ between the classic rule builder and the newer flow builder. "Advanced compare condition" does not exist under that name in the flow builder, which makes a lot of older forum answers hard to follow.

Smart value date math is easy to get subtly wrong, and it fails quietly, which is a bad property for the thing that is supposed to catch quiet failures. Test yours against a deliberately stale heartbeat before you trust it.

The obvious weakness

One issue per rule execution is real churn. If you run 150 rules on short intervals, this is not the design you want.

A better variant came out of the Atlassian Community version of this thread: one permanent control issue per monitored rule in an Automation Health project. Each rule updates a Last Heartbeat datetime field on its own control issue instead of creating a new one. The watchdog does a Lookup, then compares {{now.diff(issue.Last Heartbeat, "minutes")}} against a second field, Expected Interval (min), configured once per rule. No cleanup, everything stays JQL-searchable, and a single watchdog covers rules running on completely different cadences. That is strictly better than what I described above, and it is what I would build.

Also worth saying: most orgs do not need to monitor everything. Monitor the load-bearing rules, the ones where three weeks of silence is an actual problem, and leave the rest alone.

The part I don't have a good answer for

Who gets notified when the watchdog fires?

Fixing a broken rule usually needs admin access. But the team whose process quietly stopped working needs to know even if they cannot fix it themselves. Alert only the admins, and the affected team stays in the dark. Alert the team, and you are sending them noise they can't act on.

How are you handling that? And for anyone running 100+ rules, do you monitor any of them, or is the honest answer still that someone eventually notices?

I’ve been building a small Jira/Forge app for sharing project/task updates with people who don’t have Jira access.

Just gave the portal a complete visual redesign.

The old version worked, but it felt pretty dated, so I focused on making the whole thing cleaner, more polished, and easier to scan.

Would you prefer using the new version?

We use Jira Service Management and Assets quite heavily, and since the recent UI changes to Assets fields I've been getting more and more feedback from colleagues that the new experience is harder to work with rather than easier.

After using it myself, I think I understand why.

The biggest problem for me is the lack of clear visual structure between Assets fields.

When you have several Assets fields underneath each other, there is very little visual framing that tells you where one field ends and the next one begins. Labels, selected objects, search boxes, expand/collapse controls, “Add object”, remove buttons and Save/Cancel actions all seem to float in the same large white area.

A few examples

* Actions such as **Remove all**, **Add object**, expand/collapse and remove are positioned far away from the actual values they affect.

* Opening a field causes a significant layout change: search boxes, object rows and Save/Cancel controls suddenly appear between the surrounding fields.

* Object-level expand/collapse controls and field-level controls look very similar, while operating at different levels.

* When an object is expanded, the field becomes much taller, but there is still no strong container around the complete field.

* Multi-value Assets fields quickly consume a lot of vertical space.

* “Save changes” appears between other Assets fields, which makes it surprisingly difficult to immediately see which field is currently in edit mode.

* Empty fields, read-only fields and fields in edit mode are visually not differentiated enough.

There is plenty of whitespace, but very little visual hierarchy.

That is probably the main issue for me: whitespace has replaced borders/grouping rather than complementing them.

In isolation, each individual component probably looks clean. But once you put 8–10 Assets fields underneath each other in a real JSM ticket, the page becomes difficult to scan. There is no strong visual anchor or container telling you:

**Field → selected objects → object details → actions**

Instead, everything starts blending together.

This also matters because our service desk handles hundreds of tickets per day. These screens are not just viewed occasionally; people work in them continuously. Small usability issues therefore add up very quickly.

Several of our users also work heavily with keyboard navigation, and the new Assets interaction model does not seem particularly efficient for that workflow either. Focus, opening fields, searching, selecting an object and moving to the next field feels more cumbersome than before.

I don't think the solution needs to be dramatic. Even fairly basic visual grouping could make a large difference: clearer field containers, stronger separation between fields, actions positioned closer to the content they affect, and a more obvious edit state.

Curious what other heavy Assets/JSM users think.

Does this UI work better for you, or are you also finding it harder to scan and operate than the previous implementation?

I noticed there's a new Control category of components in automation. There's one Delay...Until that's based on time or issue events, and there's one Loop that seems to be a for loop.

I often want to say call REST API until I process all pages, so the Loop component is interesting to me. Before I have to use two automation rules and webhook, plus a way to mark processed issues, resulting in a way higher execution cost.

But it seems Loop is more like a retry component instead? I tested it, and it seems it can only do the loop 1 to 3 times, with conditions to stop it earlier.

Crazy how much you pay them for premium/enterprise, and they say looping more than 3 times is too much and not allowed.

We've created a custom field in JPD, and want it to be required on create of new Ideas.

Editing the fields, editing the type, editing the create idea... Can't seem to find where I can make our custom field appear and be required on the create dialog.

If anyone has a solution, much appreciated!!

We started using Jira Cloud with Rovo. I have been dealing with Rovo the last couple of days and must admit: I’m not a big fan. I rather use GH Copilot or Claude than Rovo to create/ modify Jira tickets, which is way more straightforward.

Hey folks,

migration projects can be a pain, especially when you need to decide what to do with all the 3rd party apps installed on Jira and Confluence Data Center.

Atlassian already provides migration assessment tooling and App Usage, and those cover a good part of the picture.

I wanted to dig a bit deeper into the actual footprint that apps leave behind in an instance.

So I built two ScriptRunner endpoints, one for Jira Data Center and one for Confluence Data Center.

For Jira, the report looks at things like app-provided custom fields, how many issues actually carry values in those fields, screen and screen scheme placements, workflow references and app modules.

For Confluence, it inventories app modules and measures actual macro usage, with current and archived spaces reported separately.

The basic question is:

If we're considering removing or migrating this app, what detectable footprint does it still have in the instance?

The endpoints generate self-contained HTML reports, with JSON and CSV output available as well.

They don't try to measure clicks, views or general runtime activity. The idea is to complement Atlassian's existing tooling with another view of the current configuration and content footprint.

I've put the scripts on GitHub in case they're useful for anyone else doing DC assessments, app rationalisation or migrations:

https://github.com/cfaysal/atlassian-dc-app-footprint

It's still evolving, so feedback is very welcome.

I'd especially be interested in hearing from people who have done larger Jira or Confluence DC migrations:

• What app artefacts have caused surprises during assessments?
• What else would you want a footprint analysis like this to detect?
• Are there areas I'm currently missing that would be worth adding?

Issues and PRs are welcome as well.

Finance wants a weekly issue dump for capitalisation reporting. Specific JQL, specific fields, lands in a shared folder and they pick it up from there.

Right now someone opens the filter and clicks Export CSV. Takes two minutes, so nobody has prioritised automating it, except the person doing it changes every few months and sooner or later finance gets a file with the wrong columns.

The obvious answer is the REST API on a cron. That's doable, but once I started looking at it the job got bigger than "export this filter." A couple of custom fields need translating into something useful, one select field comes back structured rather than as the label finance expects, and worklogs need their own handling.

At that point I'm maintaining a small transformation script for something Jira can already export manually.

What are people using for this kind of scheduled export? Marketplace app, script somewhere, or some Automation setup I'm missing?

Also, do you keep each weekly export or just overwrite the same file?

Anyone move to AGC? Thoughts? How close to “regular” cloud is it from admin and user perspectives? Any insight is appreciated.

Note: Cross-posting from r/itsm

I lead IT service desk at a decently large organization and we use Jira Service Management. There is a lot of push now to adopt and use AI to improve the desk efficiency. I have been exploring a few things like building Rovo agents, using automations, etc. As I read up, there is a lot of buzz on AI agent swarming, and how multi-agent orchestration really simplifies service desks. Has anyone successfully implemented these and seen benefits? Do other products like ServiceNow allow this? (their website seems to say so, but I am still not able to wrap my head around how this is different from automations and workflows that use some AI/ agents in them)

Also came across newer companies like Serval which sound very promising on their pages (again, looking for any actual experience after implementation)

Would really appreciate any insights into this. Thanks!

We work with a client on Jira Enterprise who ended up with several separate JSM instances (HR Global, HR EMEA, General IT, etc.) - normal result of how a large org grows, different teams/departments own different instances.

The problem: employees, and especially approvers, don't want to memorize half a dozen URLs just to check "My Requests" or "My Approvals" on each instance separately. Approvers in particular kept missing approvals sitting in an instance they don't check daily which means blocked requests, annoyed requesters, and people pinging approvers directly instead of trusting the queue.

We tried a few things before landing on a real fix: sending Slack/email reminders (helps a bit, still relies on someone clicking through the right link), bookmarks/shared docs listing all the portal URLs (nobody keeps them updated), and eventually building a single hub where employees switch between instance tabs (HR Global / HR EMEA / General...) instead of separate bookmarked URLs, with My Requests and My Approvals aggregated in one place.

Full disclosure: I work at Appsvio, and that last option became a product (UniPortal), so take this with a grain of salt. Not trying to pitch it here, genuinely curious: if you're running multiple JSM instances, how do your approvers actually keep track of pending approvals across all of them? Anything that's worked better than "just remember to check"?

Hey all — beyond atomic tasks like creating or reading individual issues, what are some **end-to-end operations** you perform (or would like to perform) as part of your SDLC workflow using Jira and related tools?
For example, are there workflows where you need to coordinate multiple Jira actions, projects, or tools to achieve a broader outcome? I’d love to hear about the real-world flows you find valuable or wish were better supported.

Is there anyone who can give Jira project management training and may be certification too?

I work for a mid size tech company, I've been routinely generating pdf reports for upper management via the API programmatically. I'd been asked to build a manager dashboard with kpi's, sla's and a bunch of other reporting metrics for the Software Support teams. So I did that with a hosted python/flask webapp, its pretty, its fast, its intuitive, tons of data but smooth organized and readable.

As upper management doesn't understand much about Jira other than they spent a metric shitton of money getting it all set up, they asked why I made a custom app rather than Jira dashboards.

I brought up the question, how many places just use the jira web interface and how many build outside tools using the API? Personally, I never open the jira website anymore, I do everything through my own tooling, even basic ticket handling of opening, commenting and transitioning ticket, cause it just seems faster, easier and more readable.

So, how common is it to use customized seperate apps to use jira?

I need clients to be able to see basic project status/progress, but I’m not really comfortable using third-party tools where our Jira data has to be sent to their servers. The alternatives I’ve looked at also feel unnecessarily complicated for something as simple as showing project status.

Is there a lightweight way to do this securely without moving our Jira data to another platform?

I'm testing the new Microsoft 365 Copilot / Graph Connector for Jira Data Center and I'm running into what looks like a permissions issue.

Setup:
-Jira Data Center (on-prem)
-Users authenticate via a different IdP than Microsoft Entra ID
-Jira username = user email address (e.g. [john.smith@metrohm.com](mailto:john.smith@metrohm.com))
-Entra UPN = same email address
-Permissions are granted through Jira groups and project roles, not individual users

What I see:
-Issues are crawled and indexed successfully.
-the Index Browser shows ACL entries like:
000-global-IT
10330
10231
10002

-The same user can open the issue directly in Jira.
-"Check user access" in the Copilot connector for this item says "Denied"
-If I switch the connector to Everyone, Copilot immediately finds and returns Jira issues.

So indexing works, but ACL-based security trimming does not seem to.

According to Microsoft's documentation, Jira groups and project roles should be supported, and the connector should resolve group membership from Jira.

Has anyone successfully deployed the Jira Data Center connector with:
-a different IdP than Entra
-Jira group-based permissions
-...and security trimming enabled?

Or are there known limitations around Jira group membership resolution?

Thanks!

EDIT:
I see no users or group memberships indexed, even after another full crawl. The permission for the connector are set to admin...

Hello everyone,

so we recently went live with out Jira Service Management.
Ive now added the field request participant to all the work item views and made sure request participant is in all the screens aswell.

But its just not showing at all.
I tried to put it into the service request customer view aswell but it instantly goes into "Hidden" and is not showing for the customer either.

We want to fill the field in case multiple people need to get notified for a service request.

Does anyone know what is happening ?

Jira, seriously, what happened to the Create Ticket dialog?

Please revert this new UI. Creating an issue is one of the most frequent and fundamental actions in Jira, and the new experience makes a simple workflow feel unnecessarily complicated.

PLEASE DO NOT CHANGE UX JUST FOR THE SAKE OF CHANGING IT.

Developers use Jira as a tool to get work done. We are not looking for a redesigned “experience” every few months. We don't need a design app. We need an interface that is fast, predictable, information-dense, and efficient.

The old Create dialog worked. You could quickly see what you needed, fill in the fields, and create the ticket.

The new one feels like someone decided that familiar workflows needed to be reinvented because the old UI wasn't visually "modern" enough.

Please bring back the old Create Ticket dialog, or at least give us an option to use it.

########## Update: There is actually a way to get the old Create dialog back ##########.

Go to:

Settings → System → General → “Simple create as default” → OFF

That brings back the previous Create Issue experience.

Huge thanks to the people who pointed this out. I genuinely thought there was no way to get rid of the new UI.

Still, the fact that you have to dig through Settings to disable a UI change that nobody asked for is… something.