DEV Community: Mariia Domska

5 Custom Jira Reports You Can Build in Minutes Using AI Prompts

Mariia Domska — Tue, 10 Mar 2026 09:30:10 +0000

Jira is a great tool, but if you manage projects for a while, you’ll notice a common problem: the report you need just isn’t there. You end up exporting data, mixing filters, or looking for yet another plugin.

Imagine if you could simply explain the report you want in everyday language and have it created right away.

With the AI Apps Builder for Jira, your team can build secure Forge-powered apps, dashboards, and gadgets with just a prompt. You don’t need to code, just describe what you want, and the AI will create a working solution ready for Jira Cloud.

In this article, we’ll look at five of the most popular custom Jira reports people ask for in the Atlassian Community. You’ll see how to create each one with a simple prompt using a no-code app builder.

Why Building Custom Jira Reports Is Still Difficult

Jira’s built-in reports work well for standard workflows, but teams often need more detailed insights like these:

Cross-project visibility
Trend analysis across multiple sprints
Workload distribution across teams
Risk monitoring across deadlines
Delivery speed metrics

When teams face these questions, they usually try one of the following:

Exporting data into spreadsheets
Building custom scripts
Installing multiple plugins
Asking developers to build an internal tool

This makes it harder for teams that just want fast, practical insights.

That’s where AI Apps Builder for Jira helps. You just describe the report you want, and the AI creates a secure Forge app with the right logic, interface, and data access—no coding needed.

Here are five helpful examples.

1. Sprint Health & Progress Report

Why teams ask for this report

Project managers often want a simple snapshot of sprint health that can be shared with leadership.

They typically want to see:

Planned vs completed work
A burndown chart
Days remaining in the sprint
Risks or blockers

Jira has a Sprint Report, but many teams find it too rigid for executive updates or dashboards.

Prompt example

Create a dashboard gadget that shows the sprint health and progress. Add dropdowns to filter by project and by sprint. Include a burndown chart of remaining story points vs. time, a summary of committed vs. completed issues, and the number of days left in the sprint. Indicate whether the sprint is on track or delayed with color-coded status (green for on-track, yellow for at-risk, red for behind schedule).

2. High-Risk Issues Tracker

In most teams, the biggest question during standups or reviews is simple: What is at risk right now?

Teams want to quickly see:

overdue tasks
upcoming deadlines
blocked issues
flagged impediments

Jira filters can show this data, but they don’t always create a clear risk monitoring view.

Prompt example

Generate a dashboard gadget that lists all unresolved issues in my project which are high-risk. Define high-risk as any issue that is either flagged (marked as impediment) or has a due date that is past due (overdue) or coming up within the next 7 days. For each such issue, display the issue key, summary, assignee, priority, and how many days it’s overdue (or days until due). Use visual alerts: highlight overdue issues in red and issues due soon in yellow.
The result is a custom report that acts like a risk radar for the team.

3. Team Performance (Velocity Trend) Report

Why this report matters
Many teams track sprint velocity, but they want more than just a single snapshot. They want to understand trends such as:

Are we improving?
Are we over-committing?
Is scope creeping into our sprints?

Jira’s Velocity Chart works at the board level, but it doesn’t provide easy trend analysis across multiple sprints.

Prompt example

Build a dashboard gadget to analyze our team’s performance across sprints. Show a velocity trend chart for the last 3 sprints, plotting story points committed versus completed in each sprint. Calculate and display the average velocity over this period, and include a trend line or percentage change to highlight improvements or declines in velocity.

This generates a custom dashboard visualization that helps teams make better planning decisions.

4. Workload Usage Report

The problem
Leads and managers often want to understand:

Who is overloaded?
How work is distributed across projects
Where time is actually spent

Jira stores worklogs, but it’s not always easy to view workload across multiple projects in one place.

With AI Apps Builder, you can generate a Workload Usage dashboard gadget that aggregates worklog data.

The custom gadget can:

Show total hours logged per user
Filter by project and assignee
Allow drill-down into individual issues

Prompt example

Create a “Workload Usage” dashboard gadget that shows total hours logged per user within a selected date range. Add multi-select filters for project and assignee, and show only users who logged time in the selected period. When I click on a user, open a table with issue key, summary, and hours logged for each issue.

This creates a reusable custom dashboard for resource planning without exporting data into spreadsheets.

5. Cycle Time Tracker

Why teams need this

Delivery speed is one of the most important Agile metrics.

Teams often ask:

How long does work actually take?
Which issues take the longest?
What is our average delivery time?

Jira’s Control Chart visualizes this data, but it is board-specific and mostly graphical.

Many teams want a simple project-wide table.

Prompt example

Create a “Cycle Time Tracker” dashboard gadget. Add a dropdown to select a project. For the selected project, show a summary with total issues, number of issues with cycle time, and average cycle time in days. Below, list all issues in a table with columns: key, summary, issue type, status, cycle time from “In Progress” to “Done.”

AI Apps Builder generates a custom report gadget that combines overview metrics and detailed issue data.

How AI Apps Builder for Jira Works

If you want to see how it works, here’s a simple overview:

First, install AI Apps Builder for Jira from the Atlassian Marketplace for Jira Cloud.
Next, open the app and begin a conversation.
Tell the app what kind of custom app, dashboard, or report you need.
The AI will then create a secure Forge app for you, including modules, permissions, a user interface, and backend logic.
You can deploy the app straight into Jira.

After that, you can keep improving your solution in the no-code builder or export the code and work with it.

And if you have a Jira report you’ve always wanted but never built, it is the best time to generate it.

Should You Code Your Forge App or Let AI Generate It?

Mariia Domska — Fri, 13 Feb 2026 13:22:05 +0000

You can now get custom Jira apps in two main ways: write code with Forge UI Kit/Custom UI, or describe what you want and let an AI Apps Builder generate the Forge app for you. Both paths produce secure, native Forge apps, but they demand very different skills, timelines, and maintenance commitments.

Use code + UI Kit when you have developer capacity and need fine‑grained control; use an AI Apps Builder when you want to move fast, prototype safely, and empower Jira users who do not write code. In many teams, the best setup is a mix: AI to explore and validate ideas, code to harden what proves valuable.

How Forge apps actually work

Every Forge app follows the same basic flow: UI in Jira, a secure bridge, and logic running in Atlassian’s cloud. Jira renders your app inside an iframe on an issue view, project page, or dashboard, and your UI code handles user interactions in that iframe. You build the UI either with Forge UI Kit (pre‑built Atlassian components) or with Custom UI (your own React or other frontend) hosted by Forge.

The UI never talks to Jira “raw”; all app‑level Jira and external API calls go through the Forge backend via @forge/api, which enforces scopes and user permissions. Your UI calls backend functions using @forge/bridge (for example, invoke()), and resolver functions in the Forge runtime handle those calls, use requestJira(), talk to Forge Storage or SQL, and return results.

In a simple flow, a user clicks a button in an issue panel, the UI calls invoke("doSomething"), the resolver runs business logic and a Jira REST call, then returns data that the UI uses to re‑render.

Whether you write every line of this yourself or let an AI Apps Builder scaffold it for you, your app still runs inside this same architecture.

Coding your Forge app with UI Kit: control and cost

What “coding a Forge app” actually means

Building a Forge app with UI Kit is less about fancy visuals and more about clean flows and platform rules. You structure logic like: “When the user clicks this button, call the backend, fetch Jira data, maybe store something, and update the UI with the result.” In code, that means writing JavaScript for resolvers and triggers, managing state between UI and backend, and defining a manifest.yml that wires modules, resources, functions, and permissions.

With UI Kit, you describe your interface using Atlassian’s components instead of raw HTML and CSS, which makes apps visually align with Jira and other Atlassian products. Any action that needs Jira data, storage, or external APIs goes through the backend via invoke() and @forge/api, not directly from the browser, which keeps security consistent.

Learning curve and realistic timelines

Becoming productive with Forge is more than “install the CLI and go”; you need an intermediate level of JavaScript plus familiarity with Forge concepts. For someone who already knows JavaScript basics, a realistic progression looks like this:

After about 3–6 months of steady practice (5–10 hours/week), you can usually: understand Forge examples and starter apps, modify templates, and build simple apps (for example, an issue panel that reads fields and stores a small configuration).
Over 1–2 years of regular work on Forge, you reach the point where you can: choose sensible architectures without guessing every time, handle edge cases and tricky permission issues, and maintain apps over multiple releases without feeling like you are constantly starting over.

Once you know the platform, build times still vary with scope:

Simple app (one panel, one–two Jira calls)
Example: an issue panel with a button, one requestJira() call, and a bit of storage.
For an experienced Forge developer, this is often 1–3 days of focused work.
“Real” app (Custom UI, multiple resolvers, events, external API)
Example: a custom dashboard or rich panel that pulls data from Jira and a third‑party service, with scheduled triggers.
Getting to something stable and shippable usually takes 1–2 weeks.
Complex production‑grade app
Example: multiple screens, queues for background work, performance tuning, security reviews, and robust error handling.
These apps are measured in months and usually involve a small team, not one developer.

Most of this time is not spent typing code: it goes into clarifying requirements, reading Forge and Jira REST documentation, debugging deployment and permission issues, and iterating on UX so the app feels natural inside Jira.

UI Kit in 2026: why its history still matters

UI Kit 1 is gone, but the migration pain remains. UI Kit 1 is now fully deprecated and has not been functional since 28 Feb 2025, which means any UI Kit 1 modules show errors instead of real UI. That is why some older apps feel “partially broken” even though they remain installed: the backend logic may still run, but the UI surfaces backed by UI Kit 1 no longer render.

Migrating those apps to the latest UI Kit has required real refactoring work rather than a simple dependency bump:

Components such as Avatar and AvatarStack were removed and replaced by User and UserGroup.
Props changed on components like Badge and Button (for example, text moved into children, disabled became isDisabled, and icon props were renamed).
The manifest had to be updated to use resources (frontend entry files) plus render: native, instead of the older single-function field.

For Marketplace vendors, there has been another challenge: when the migration added or changed scopes, it forced a major version that each customer admin had to manually approve. In practice, that left some customers stuck on older, now‑broken versions simply because nobody had clicked “Approve new permissions” in time.

Visual stability and long‑term UI choices

Forge UI Kit is closely tied to Atlassian’s design system, which is a blessing for consistency and a risk for visual stability. When Jira’s global UI changes, UI Kit components can change too, without you shipping a new app version. A clear example is the component: when Jira rolled out a new navigation and updated tag styling, UI Kit tags went from solid coloured labels to subtle outlined chips, making colour cues much less obvious for users who relied on colour to scan quickly.

Partners have also highlighted that Atlassian has had several incompatible UI stacks over time: AUI, Atlaskit, UI Kit 1, and the current UI Kit—and each shift has carried migration costs. That history makes teams think carefully before investing heavily in UI Kit for large, long‑lived UIs.

The good news is that the latest UI Kit is far more capable than the original:

It ships with richer components such as charts, comment UIs, Pressable, and layout primitives like Stack, Inline, and Box, which make more complex layouts possible.
The Frame component lets you embed HTML, CSS, JavaScript, and even Custom UI‑style content inside a UI Kit screen, effectively giving you a blend of simplicity and flexibility.
The trade‑off is clear: UI Kit gives you opinionated, fast‑to‑build UIs that match Atlassian products, but you accept a higher chance of refactors when the design system or UI Kit API evolves, and you plan for scoped permission changes and admin approvals when you upgrade.

Letting AI generate your Forge app: Custom UI power from prompts

Start from your Jira use case, not from modules and manifests
An AI Apps Builder for Jira lets you start with the workflow you want to support, instead of starting with Forge concepts. Instead of thinking “issue panel vs dashboard vs global page” or “UI Kit vs Custom UI,” you write prompts like:

“Create a gadget that shows issues assigned to the current user with due dates in the next 7 days, showing key, summary, status, and due date, sorted by nearest due date.”

“Create an issue panel that reads the issue’s due date and displays a live countdown timer, and if it is overdue, show ‘SLA breached’ in red.”

You do not decide which resolvers to use or which scopes to add; you describe what you want Jira to do, and the AI maps that intent to a Forge app structure.

What the AI Apps Builder actually does

A mature AI Apps Builder behaves like a Forge‑aware internal developer:

It chooses Custom UI for rich interactive experiences.
It generates frontend code, backend resolvers, and a manifest.yml with modules, resources, and scopes.
It validates that the app is consistent with Forge’s security and deployment rules and is ready to install.

From Forge’s perspective, the result is a standard Forge app: JavaScript code, manifest, resources, scopes, and deployment artifacts that run inside Atlassian’s infrastructure. From your perspective, it feels like you described the solution in English and got a working app in Jira that you can iterate on.

Why this no‑code path is so useful for Jira users

Under normal circumstances, Custom UI means React, bundlers, state management, styling, and strict iframe security rules. An AI Apps Builder hides that complexity and applies Forge best practices for you:

It chooses reasonable layout and state patterns so you do not have to learn React from scratch.
It ensures that all Jira and external API access goes through the Forge backend and @forge/api, with the right scopes and permission checks.

This lets Jira admins, project managers, team leads, and power users:

Quickly prototype issue panels, project dashboards, checklists, and custom reports by iterating on prompts instead of tickets and specs.
Adjust apps by talking to the AI (for example, “add a status filter” or “show only my team’s projects”) rather than editing code.
Hand off successful apps to developers later for performance or complex integrations, using the generated code as a starting point rather than rebuilding from zero.

Developers still benefit because AI can generate the first Forge app—modules, manifest, plumbing, and basic UI—leaving engineers free to focus on hard problems. Since the result is a regular Forge project, it fits into existing repos, code review processes, and security checks.

Code + UI Kit vs AI Apps Builder: a quick decision table

Question	Code + UI Kit	AI Apps Builder (Custom UI + LLM)
How fast can we get a first working app?	After learning Forge basics and JavaScript, simple apps take days and larger apps take weeks.	Often within minutes: describe the panel, dashboard, or page you want and let the agent generate a deployable app.
Do we need to code?	Yes. You need JS, Forge modules, manifests, scopes, and a willingness to handle UI Kit migrations.	Not for initial versions: you work in prompts, but you can still download and edit the generated code if needed.
How stable is the UI over time?	Strongly tied to Atlassian’s design system; UI Kit components can change appearance or APIs, requiring refactors and major app updates.	Uses Custom UI, giving more control over layout and styling; still subject to Forge changes, but less exposed to UI Kit-specific visual changes.
Who is this best for?	Teams with developer capacity that want maximum control and are comfortable maintaining code and handling platform changes.	Power Jira users and teams with limited developer time who need internal tools quickly and want to iterate from real usage.
How does it behave in Jira?	As a standard Forge app using UI Kit, running in an iframe with resolver-based backend logic, scopes, and auditability.	As a standard Forge app generated by the AI, with Custom UI, resolvers, scopes, and deployment all within Atlassian’s Forge model.

Which option should you choose?

Code + UI Kit makes the most sense when:

You have developers available and you want full control over behaviour, performance, and long‑term architecture.
You expect to iterate on the app for years and prefer to keep everything in your normal codebase, CI/CD, and review process.
You are comfortable planning for UI Kit and design‑system changes, including refactors and permission updates.

An AI Apps Builder is the better starting point when:

You need a working solution fast, from first idea to something Jira users can click on.
You are a Jira admin or PM who does not have time to learn Forge or to wait for a full dev cycle.
You want deployment to be easy, but also want the option to hand the generated code to developers later for hardening or extension.

If your main constraint is time, Forge’s complexity, or limited developer capacity, an AI Apps Builder lets you turn “we wish Jira could…” into a real app by having a simple conversation.

When Marketplace Apps Don’t Fit: Building Custom Jira Tools on Atlassian Forge

Mariia Domska — Wed, 21 Jan 2026 11:58:44 +0000

If you’ve worked with Jira long enough, you’ve probably run into this situation:

“We need a small internal tool — nothing fancy.”

Maybe it’s:

a report that combines Jira data in a very specific way
a workflow helper tied to your SLA logic
a dashboard that almost exists, but not quite

You check the Atlassian Marketplace, try a few apps, and quickly realize the problem: marketplace apps optimize for breadth, not your edge cases. At that point, teams typically choose between living with the gap or opening a custom dev ticket for a “small” internal app.

This post describes a third option: using an AI-based builder to generate native Forge apps without writing boilerplate or standing up infrastructure.

Why Marketplace Apps Break Down for Internal Tooling

Marketplace apps are well-engineered, but they’re constrained by design:

one configuration model for many customers
limited customization without exploding complexity
slow iteration for highly specific workflows

When an app almost fits, teams usually fall back to:

CSV exports
spreadsheets
custom scripts running outside Jira

From a technical perspective, this creates problems:

duplicated business logic
data leaving Jira’s permission model
fragile, undocumented tooling

Building internal tools directly on Forge solves many of these issues — but Forge development itself has overhead.

A Different Approach: Generating Native Forge Apps

AI Apps Builder is an AI-based Jira app that generates native Atlassian Forge apps from natural-language prompts.

Within a few minutes, you get the real Forge app code:

using supported Forge modules
deployed inside Jira Cloud
governed by Jira permissions and scopes

There’s no external runtime, no custom auth, no separate backend.

How the AI Apps Builder Works

You can think of the system as an automated internal tooling pipeline that replaces:

initial requirements translation
boilerplate Forge setup
first-pass UI and logic wiring

1. High-level flow
2. Prompt interpretation
The system parses the prompt to identify:

required Jira entities (issues, fields, users, dates)
expected UI components
interaction patterns (filters, aggregation, navigation)

3. Solution planning
It determines:

which Forge modules to use (global pages, issue panels, config pages),
what data access scopes are required,
how UI and logic should be separated,

4. App generation
AI generates:

manifest.yml
Forge UI components
resolver functions and business logic
configuration.

5. Iterative refinement
Code is validated, adjusted, and regenerated until the app is consistent.

Under the Hood: Agent-Based Generation

This is not a one-shot code generator. The AI Apps Builder uses an agent-based flow inspired by a ReAct loop:

reasoning about the next step
executing a specific action (code generation, validation, file update)
reviewing the result
repeating until completion

That loop is what allows:

multi-page apps
non-trivial business logic
consistent configuration across files

Key constraints (by design)

Code is generated only from public Atlassian Forge documentation
No private Jira data is used during generation
The output is a native Forge app, not a wrapper or external service.

Security Model: Why This Works in Enterprise Jira

Most AI tooling fails security reviews because it:

runs externally
proxies data
or bypasses platform permission models

Forge avoids this by design — and the AI Apps Builder doesn’t change that.

What this means in practice

Apps run entirely inside Atlassian Cloud
Authentication and authorization use Jira’s native model
Access is limited to explicitly granted scopes
No external databases or backends by default

From a security and compliance perspective, these apps behave like any other Forge app.

Example: Generating a Worklog Reporting App

One internal app generated with the AI Apps Builder is Worklog Summary Reporter.

It produces a consolidated worklog report for:

selected users
selected projects
a defined time range

Without:

CSV exports
spreadsheet aggregation
external reporting tools

This replaces:

multiple Jira filters
repeated manual aggregation
ad-hoc reporting scripts

When This Approach Makes Sense

This model works well when:

you need internal tooling, not Marketplace distribution
workflows are specific to your org
security and governance matter
building and maintaining custom Forge apps is overhead you want to reduce

It’s not a replacement for hand-written Forge apps — but it is a fast way to: prototype, validate, and ship internal Jira tools.

Getting Started (Minimal Friction)

Install AI Apps Builder from the Atlassian Marketplace
Pick one internal workflow with high manual overhead
Write a precise prompt (entities, fields, output format)
Generate, deploy, and test inside Jira.

Or you can try the live demo of AI Apps Builder right now.