Jira's native integrations cover a lot of ground — Slack, Microsoft Teams, Confluence, Bitbucket, and most of the dev tools your team already uses. But native integrations are built for standard workflows. The moment your team needs something more specific, you're out of luck unless you can write a Forge app yourself.
This post walks through what that "something more specific" usually looks like, and how AI Apps Builder lets you go from a plain-language description to a deployed, working integration — no code required.
The problem: native integrations stop at "standard"
Say your team wants to:
- Monitor a Gmail label and auto-create Jira issues from matching emails
- Pull action items out of Notion meeting notes and turn them into Jira sub-tasks
- Trigger a chain of actions the moment an issue moves to "Done"
None of these are exotic request. They're the kind of thing ops leads and PMs sketch on a whiteboard all the time. But they fall outside what Jira's built-in connectors support.
This is the gap custom Forge apps are meant to fill — and historically, building one meant knowing Forge, understanding Atlassian's permission model, and writing the authentication flow by hand.
What AI Apps Builder actually does
With AI Apps Builder, you describe the integration you want in plain language, and it generates a working Forge app in response — authentication included, configuration UI included, deployed directly into your Jira environment. No coding.
It supports three types of external API connections:
- Public APIs — no authentication required
- API key authentication — for tools using token-based access
- OAuth 2.0 — for tools like Gmail and Google Drive that use a standard sign-in flow
Out of the box, it supports Slack, Gmail, Google Drive, Google Calendar, HubSpot, and Notion, plus any other tool that exposes a public or authenticated API.
How building an integration actually works
You describe what the app should do. AI Apps Builder generates a complete Forge app — the HTTP calls, the authentication method, and any configuration fields the app will need.
If the app requires an API key or OAuth, the builder also generates an admin page automatically. On that page, a Jira admin can:
- Follow step-by-step setup instructions for the external side of the integration
- Enter the required credentials (API key, client ID/secret, OAuth token)
- Provide resource identifiers the app needs (database ID, workspace, project label)
- Test the connection and save settings.
Once that's done, the app is ready to use. Because it runs entirely on Atlassian's Forge platform, all API calls happen inside Atlassian Cloud — your credentials and data stay within Atlassian's existing security and permission model.
Real example: a support ticket generator, from one prompt
Here's what the process looks like end-to-end. The prompt:
Build a service that monitors my Gmail for support requests and drafts Jira tickets for them.
Before generating anything, AI Apps Builder asked five clarifying questions:
| Question | Answer |
|---|---|
| Where in Jira should this app live? | Global page (standalone full page) |
| What should the app do when it finds a support email? | Automatically create Jira issues without review |
| How should the app identify support request emails? | A specific Gmail label (e.g., "support") |
| Which Jira project and issue type? | Configure in app settings |
| How will the app connect to Gmail? | OAuth 2.0 (Google sign-in flow) |
From those five answers, it generated:
An admin settings page at Jira Settings → Apps → Support Ticket Generator — Settings, including step-by-step instructions for setting up the Google OAuth client, fields for Client ID and Client Secret, a callback URL to paste into Google Cloud Console, a test connection button, and configuration for the Gmail label and target Jira project.
The app itself, a global page called Support Ticket Generator, accessible from the Jira sidebar under Apps. It shows Gmail connection status, a Sync Now button, the last sync time, and a table of recently created issues with key, summary, reporter, and creation date.
All of it — the OAuth flow, the admin UI, the issue creation logic — came from one prompt and five answered questions.
Real example: pulling action items out of Notion
Second example, different pattern. The prompt:
Extract all 'Action Items' from my latest Notion meeting notes and create Jira sub-tasks for them.
Four questions this time:
| Question | Answer |
|---|---|
| Where in Jira should this app live? | Issue panel (inside a Jira issue) |
| How should the app find your Notion meeting notes? | Notion API token + database ID, configured in app settings |
| How should sub-tasks be created in Jira? | Under a specific Jira issue, chosen each time |
| Preview action items before creating sub-tasks? | Create automatically, no preview |
What got built:
An admin settings page at Jira Settings → Apps → Action Item Extractor Settings, with a six-step guide to creating a Notion internal integration, a masked token field, a Database ID field with a hint showing exactly where to find it, and a test connection button that confirms a successful connection.
An issue panel that pulls the latest meeting note from the connected Notion database, displays the extracted action items as a checklist, shows which issue the sub-tasks will attach to, and offers a single "Create Sub-tasks" button.
The app sits inside the issue, next to the context it's actually relevant to — no separate page to go find.
The pattern generalizes
Gmail (OAuth) and Notion (API key) are just two examples of the same underlying pattern. Teams have described and built things like:
- Slack → Jira — a Slack command triggers a deployment, creates a Jira ticket, sends an email, and updates task status, all automatically
- Jira status → chain of actions — an issue moves to "Done" and triggers a Slack notification, a draft release note, a dashboard update, and closes a linked support request
- Gmail → HubSpot + Jira + Slack + Google Calendar — an incoming enterprise request email creates a HubSpot lead, opens a Jira issue, notifies sales in Slack, and books a meeting
Each one starts as a single prompt and ends as a deployed Forge app.
Why the location of the integration matters
The value here isn't only the connection — it's where that connection lives. Because these are built as Forge apps:
- They show up natively inside Jira — issue panels, admin pages, global pages, wherever you deploy them
- They respect Jira's existing permission model, the same access controls already governing everything else in your instance
- They don't require a separate integration platform, and they don't need a developer to maintain them afterward.
Where your data actually goes
All external API calls run from the Forge app inside Atlassian's cloud. Credentials and data don't leave Atlassian's infrastructure.
The AI's role stops at code generation — it doesn't connect to Jira, doesn't read your data, and doesn't talk to the external services your app integrates with. Once deployed, the app runs entirely under standard Forge permissions, the same model that governs every other app in your Jira environment.
The AI generates the code. Atlassian Forge runs it. Your data stays within Atlassian's infrastructure throughout.
Try it with something your team already needs
AI Apps Builder lets you connect Jira to tools like Slack, Gmail, Google Drive, Google Calendar, HubSpot, and Notion by describing what you want in plain language. It handles authentication, builds the configuration UI, and deploys the result as a secure Forge app inside Atlassian Cloud — no integration code, no waiting on a dev queue.
Install AI Apps Builder for Jira from the Atlassian Marketplace and start with an integration your team is already missing. You get 50 credits to start — describe the connection and see what it generates.
Top comments (0)