Existing epics/tasks cannot be opened, and a new task/epic also cannot be opened after they're created. I see the following error that I've never seen before. Nothing has changed with our project; permissions are as they were.

We couldn't connect to that work item.

Make sure that this work item actually exists in that space. If it does, try again in a few minutes. If you still can't link to the work item, contact your Jira admin.

I rebuilt one myself using the API keys and wondering if others might be doing the same.

So this is my first role as a junior Jira admin and my team lead mentioned Elements Connect is something I'll need to learn pretty fast. I've been reading the docs but wanted to hear from people who actually use it day to day before I dive in deeper.

Is it possible for ChatGPT to read/create ideas from/to Product Discovery via the Atlassian Rovo GPR app integration?

If not, is there some other way I can connect PD to an AI?

I'm building out Jira for our company. One thing we want is for users not in the dev team to be able to see a space to understand where their item fits. I've tried following these instructions but it still makes me log in: https://jira.atlassian.com/browse/JRACLOUD-85673

Is there a way to set a timeline view or something so that people could see it with just a link?

JSM admin at a 900 person org. Most of our IT requests start as slack threads in our #it-help channel. Ticketing flows the wrong way for us right now: tickets get manually copied into JSM after the slack thread resolves, which is when our ITIL person remembers.

Looked at automation rules + JSM API + a couple of marketplace apps. The marketplace ones either copy slack messages on a webhook (one-way) or require a paid bridge subscription per user that gets expensive at our scale. Atlassian assist seems focused on customer portals not internal slack channels.

What I actually want: thread in slack, ticket gets created in JSM with the slack thread URL attached, replies in either side post to the other automatically until the ticket closes.

Has anyone actually built this and made it stick? Or is there a tool I am missing? Genuinely open to you cant get there from here, switch tools if that is the answer.

Hello everyone. I'm totally new to the whole Jira and AI thing and I'm not even really sure how to formulate this question.
My company wants to integrate a chatbot into our Intranet that helps with first-level IT-Support. It should offer solutions to the most common problems and generate a jira ticket in the background for more complex problems that need fixing by a person.

Does anyone have experience with this or knows any tools that already do something like that? Thanks in advance

After investigating a feature request, figuring out a dozen points, adding different findings, and coming up with a different edge-cases, I had a finger spasm that caused me to press cancel and everything is gone.

Thanks Jira.

I have 5+ years of experience with Jira, including strong knowledge of schemes, permissions, workflows, and ScriptRunner for automation and customization.

Open to roles or collaborations ;)

Also have some with other Atlassian tools, such as Confluence, Bitbucket and Crowd

I’ve also trained team members on how to use these tools effectively and explore their full potential

​

I’ve been testing Atlassian Rovo, and while the "AI Agent" hype is real and in some cases it is good, the governance implications are honestly terrifying.

Is anyone else worried about these three things?

Workflow Chaos: We’ve spent years perfecting Jira automations and guardrails. Now, AI agents are essentially creating "shadow workflows" that bypass the logic we’ve spent thousands to build.

The Access Paradox: These agents have massive reach. It’s scary how easily they can surface context from sensitive resources that the prompting user shouldn't actually see, simply because the agent has site-wide indexing power.

The Identity Void: This is the biggest red flag. When an AI agent leaks data, whose identity was used? * Does the audit log blame the user who prompted it?

The admin who installed it?

Or is "Agent Identity" a total blind spot in our current access policies?

We’re giving these agents more access than our senior architects, but we have zero way to govern them under "Least Privilege" rules.

Are you guys actually rolling this out to production, or is the lack of auditing a dealbreaker for you?

Hi everyone,

I would like to create an automation to create and epic when selecting a component. Then create 2 tasks that are issues inside the epic created. Thanks.

Hi all,

I've been tasked with integrating automated triage in our Jira workflow. I'm not an expert by any means but seeking advice as to what would be suitable to meet our requirements.

Currently, tickets are created via a page we have set up which I believe is the "Customer Services Desk" feature of Jira. We must manually review each support desk ticket and SLAs to determine its priority and whether it must be handled in the current or next sprint depending on the urgency.

We are looking to automate this and I'm seeking advice as to:

- How we can approach this

- What the workflow would look like (e.g assigning labels, changing ticket status etc?)

- Which Jira tools we can make use of

I have heard the use of AI (Rovo?) may be appropriate here to analyse the ticket to determine its priority.

Additionally when replying to the customer under support desk ticket, we are looking for a method to generate a suggested reply based on the context of internal comments on the support desk ticket.

Please advise.

Many thanks in advance.

Hello all! I am the closest thing my company has to a Jira admin and I know I have so much to learn. Here is my current predicament that has me 100% stuck:

I want Jira to automatically add a Flag (red flag with impediment) when a work item moves to the status of "Blocked". That part is working fine. However, I cannot figure out how to have Jira automatically remove the flag/impediment when the work item leaves the "Blocked" status.

Here is the automation as it currently stands:

When: Work item transitioned - From status = blank, To status = Blocked

Then: Edit work item fields - Flagged - Impediment.

Logically (and according to Rovo), the Flag/impediment should remove itself when the work item is moved away from the "Blocked" status but it is just not working!

What am I doing wrong? What am I missing? Is this even possible to achieve?

SOLVED: I needed one rule for items becoming blocked and one for items becoming unblocked.

I am also going to apologize for future, equally obvious questions. Y'all rock!

I'm working on putting together some Rovo Agents for training but I can't find a comprehensive list of skills anywhere. I can type things and some come up, but other things I think should come up don't. Any lists from Atlassian I've found are from 2025.

It's Wednesday. Your CEO asks why the Q3 launch slipped two weeks.

You open Atlassian Roadmaps. It shows ten epics in a timeline. None of

them are connected. There's no critical path. There's no baseline you

saved last sprint to compare against. You can see WHAT slipped, not

WHY. So you go to the Marketplace and discover that every Gantt plugin

charges $1.50–$2.50 per user, billed from user 1, and your 5-person

team is suddenly looking at $66 to $125 a month for a chart.

Most teams either pay it through gritted teeth, or live without and

keep guessing. The "cheap alternatives" further down the search are

mostly 2-star apps with 2018-era screenshots.

There's a third option as of last week.

What you'll see when you open it

================================

The whole project on one screen:

- Spreadsheet on the left (key, summary, assignee, dates), Gantt on

the right

- Drag a bar to reschedule — the change writes back to Jira instantly

- The bars on the critical path are red. The one causing your slip is

the one with everything red downstream of it

- Saved a baseline two weeks ago? Ghost bars overlay the chart so you

can see the drift, task by task

- Drag from the end of one bar to the start of another → dependency

arrow, auto-detects FS / SS / FF / SF

- One click → "Standup mode": filters to active sprint, hides done,

flat view, day zoom, sorted by assignee. Run your standup off it.

It runs entirely inside Atlassian Forge. No external server, no data

leaving your tenant, no credit card to install, no trial expiry.

Pricing

=======

- Free for everyone right now (paid launch is Aug 1, 2026)

- Free FOREVER for teams up to 10 users — not a trial, the actual

free tier

- $1.20/user/month for 11–100 users (about a third of BigGantt)

- Scales down to $0.04/user at enterprise headcount

Try it without installing

=========================

Live screenshots from a real Jira project (no install, no login):

[link in first comment]

2-minute screen recording of the auto-scheduling and critical path

in action: [link in first comment]

If it looks right, the Marketplace install is 30 seconds. Forge

deletes everything if you uninstall — there's nothing to clean up.

Honest stuff

============

- It just shipped. Zero reviews on the Marketplace yet. Be the first

to leave an honest one (good or bad)

- 3.15.1 has the resource-leveling UI in place but the backend isn't

wired yet — that lands next release

- Cloud only, no Data Center build

- Best-effort support via GitHub issues, not enterprise SLA

Disclosure: I'm the publisher. Posting here because the pricing gap in

this category has been a Jira-team complaint for years. Atlassian's

policy means I can't ask for installs or reviews directly — just

showing it exists.

Curious what the rest of you do

================================

For those of you on BigGantt or WBS today: what's the ONE feature that

keeps you on it that's worth $1.50/user/month? Trying to figure out if

that's a real moat or just switching cost.

https://preview.redd.it/gxb5r7dpfdxg1.png?width=1840&format=png&auto=webp&s=91f3f49ac69932ed51e7839ccba80dfa98c98075

TL;DR: We migrated 2,900+ YouTrack issues to Jira ourselves using a custom Python engine built with Claude. A two-week POC saved us — it caught ADF failures, type mapping gaps, and relationship bugs before they could touch production. The main migration ran over a weekend. Things still went wrong. This post is the honest account of what they were and how we fixed them.

We built a custom Python migration engine entirely with Claude — no consultants, no professional services engagement. Just AI, a mapping file, and a lot of edge cases.

I'm writing this because when I was planning it, there was almost nothing useful out there. Most of what I found said: use Jira's built-in import tool. That works for simple cases. Ours wasn't simple. This is the honest account I wish I'd had.

The real problem

YouTrack wasn't broken. It had just quietly become its own source of friction — workflows too complex, custom fields multiplied past usefulness, no clean picture across teams. Moving to Jira wasn't the goal. Resetting was.

The scope

• 2,900+ issues across multiple source spaces in YouTrack, landing across multiple Jira projects
• Several source-to-destination project mappings, some consolidating multiple YouTrack spaces into a single Jira project
• Everything had to come across: descriptions, comments, work logs, attachments, relationships (parent-child, blocks, implements, relates), custom fields, story points, and resolution states
• Zero tolerance for duplicates — we needed to run the migration incrementally without re-creating issues that already existed

Pre-migration: metadata analysis first

Before writing a single line of migration code, we did a full metadata analysis across every YouTrack project — issue types, custom fields, relationship types, states, priorities, and hierarchy. Understanding the shape of the data before touching it is what made each project's migration as clean as possible. Skipping this step means rework.

The approach: incremental migration with a mapping file

The first thing we built was a mapping file — a JSON file tracking YouTrackID → JiraID for every migrated issue. The design: before creating anything, check the mapping. If it's there, skip it. The goal was to run the migration as many times as needed without duplicates, migrating in batches rather than a big-bang cutover. Getting that truly idempotent took more iteration than expected — edge cases in how the mapping was being written let some issues slip through. More on that in item 8.

We also built a --dry-run flag from the start. Every run prints what would happen without touching anything. This saved us several times. All Jira updates used notifyUsers=false to avoid spamming the team.

What went wrong (the useful part)

Before the main migration, we ran a full POC on a single project — two weeks out, deliberately, to stress-test the engine in a lower-stakes environment. That decision is what made the main migration as clean as it was. Most of the problems below surfaced in the POC and were fixed before the main run. A few didn't show up until later. I've noted which is which.

1. Atlassian Document Format (ADF) is not Markdown

(Caught in POC) Jira's API doesn't accept Markdown. It expects ADF — a proprietary JSON structure where every paragraph, heading, bullet, and inline code span is a nested node. We had to write a markdown_to_adf() converter from scratch. The POC revealed it fell apart for edge cases. ADF and formatting problems were the single biggest source of rework throughout the migration — more than any other category, and the reason the POC approach proved so valuable.

2. Inline code spans were eating angle brackets

(Caught in POC) YouTrack descriptions used backtick inline code spans like \<some_value>``. Our converter ran HTML unescaping on content before parsing backtick spans — so the angle brackets were being stripped as HTML tags, leaving an empty string. The fix: a protect/restore pattern that replaces angle brackets inside backtick spans with null-byte placeholders before HTML processing, then restores them after ADF conversion. Fixed before the main migration ran.

3. The merged-text bug

(Caught in POC) For some issues, the entire description — headings, bullets, tables, everything — collapsed into a single ADF paragraph node with raw Markdown as literal text. One giant wall of syntax characters in Jira. Root cause: an edge case where the converter failed to split content into blocks and fell back to dumping everything into one node. 25 POC issues identified, converter patched, main migration ran clean.

4. Issue type mapping was wrong in the early batches

(Caught in POC) YouTrack has Feature, Enhancement, User Story, Documentation. Jira has Epic, Story, Task, Bug. We built a type mapping, but a frequency audit of POC output showed gaps — Feature issues landing as Story instead of Epic, Enhancement silently defaulting to Task. The 16 wrongly typed issues were in the POC project and corrected before the full migration ran.

5. Features required special hierarchy considerations

Our Jira instance doesn't have the same hierarchy as YouTrack. In YouTrack, Features sit above Epics and can span multiple projects — Jira has no native equivalent. This required project-by-project decisions about how Features should be represented in each destination, and in some cases custom field workarounds to preserve hierarchy context.

6. Blocking relationships arrived reversed

(Surfaced post-main-migration) YouTrack stores link relationships with an explicit direction per issue — INWARD (this issue is blocked by) vs. OUTWARD (this issue blocks). Our initial script read the link type name without checking direction. Result: "Issue A blocks Issue B" could arrive in Jira as "Issue B blocks Issue A." The relationship existed; the meaning was flipped. The fix required rebuilding the link migration logic with full direction-awareness and running a retrospective fix pass across all previously migrated issues. Don't assume the link type name tells you which way the relationship points.

7. Cross-project relationships

Parent-child links in Jira are intra-project only. But in YouTrack, a Feature in one project could have child Epics in three other projects. Our solution: cross-project parent-child relationships become Relates to issue links. We built logic to detect when a relationship crossed project boundaries and handle it differently — including a sequencing fix, since children migrated before their parent won't get the parent link set automatically. The script re-runs relationship migration on every execution.

8. Duplicate issues from re-runs

During one source space migration, issues were created more than once before idempotency was fully hardened. The mapping file check was in place, but an edge case in how the mapping was being written let some issues slip through. Identifying, cross-referencing, and cleaning up duplicates was tedious. "Idempotent" needs to be verified end-to-end, not just assumed. And for issues relevant to multiple destination projects: establish a hard rule — once an issue is migrated, it does not get a duplicate in another project.

What we'd do differently

The single most important thing: run a POC on one project before migrating everything. We did — two weeks out — and it changed the shape of the main migration entirely. Most of the issues above were caught and fixed there, not in production.

• Build the ADF converter test suite against edge cases, not just happy paths. Tables, nested bullets, inline code with special characters, headings at line one — the POC revealed all of these. Build that corpus before your first real run.
• Do a frequency audit of every issue type before writing the mapping. A five-minute count across all projects shows you exactly where the gaps are before they land in Jira at scale.
• Automate the formatting verification check and run it with every batch. Build it in the POC, automate it, and it's just part of the pipeline by the time the main run happens.
• Map and validate every link direction before migrating. Don't assume the link type name tells you which way the relationship points. INWARD and OUTWARD are not the same thing, and getting it wrong means all your blocking relationships are backwards.
• Migrate relationships in a separate dedicated pass. Bolting it onto the main script creates ordering dependencies that are much cleaner as a standalone step.
• Plan a dedicated post-migration pass for cross-project relationship reconciliation. Once all projects are live in Jira, run a targeted pass to verify and update all cross-project relationships. Easy to deprioritize; painful to clean up later.

The cleanup that came with it

The migration was also an opportunity to undo years of accumulated tooling debt. We intentionally chose not to port complexity — and the numbers reflect that:

• Issue types: 7 → 4 (43% reduction — types folded, consolidated, and relabeled to match how work actually gets done)
• Priority values: 10 → 5 (overlapping and rarely-used values rationalized to 5 clearly-named Jira priorities)
• Workflow statuses: 8 → 6 (ambiguous terminal states collapsed into Done with resolution values set)
• Workflow configurations: 20+ → 2 — and this number was inflated for a specific reason: YouTrack had been used to automate build pipeline triggers and release creation directly within its workflow engine. Deployment-specific logic was embedded in the same state machines as issue tracking, duplicating effort and making the workflow landscape far harder to maintain than it should have been. We chose not to migrate any of that. Build pipeline and release automation now live in the CI/CD pipeline where they belong. All 7 projects run on one of two shared schemes — Scrum or Kanban.
• Labels: unmanaged tag set → 6 operational labels (everything else was noise and deliberately left behind)

The outcome

Everything made it across. 2,900+ issues, all relationships intact, comments, work logs, attachments, custom fields — clean. The team is fully off YouTrack. The incremental engine means we can still run it for any stragglers without touching what's already there.

And this is only the start

This was our first major project built entirely with Claude. Since then it's become a new way of working — if we need a capability, we build it. Timesheet reporting instead of Tempo. Incident mobilization. Discovery analysis. The question is no longer whether it's possible. It's how fast.

Happy to answer questions

If you're planning a similar migration and want to talk through the ADF converter, the mapping strategy, or the relationship handling - ask away. I have opinions.