Build Custom Forge Apps with Integrations from a Single Prompt

[#1]

Jira offers strong native integrations with popular tools like Slack, Microsoft Teams, Confluence, Bitbucket, and several development platforms. For many teams, these built-in options are all they need.

However, native integrations only support standard workflows. If your team needs something more specific, like monitoring a Gmail label to auto-create Jira issues, extracting action items from Notion meeting notes, or triggering a series of actions when an issue moves to "Done," the built-in connectors may not be enough. In these cases, custom Forge apps are the solution.

With AI Apps Builder, you can describe your custom integration in plain language and receive a working Forge app in return. Authentication is set up, the configuration UI is generated, and the app is deployed directly in your Jira environment. No coding is needed.

What integration support actually means

AI Apps Builder supports three types of external API connections:

• Public APIs — no authentication required

• API key authentication — for tools that use token-based access

• OAuth 2.0 — for tools like Gmail and Google Drive that use a standard sign-in flow

Supported tools include Slack, Gmail, Google Drive, Google Calendar, HubSpot, and Notion. You can also connect to any other tool that offers a public or authenticated API.

How to build a custom app with integration

You describe what you want the app to do. AI Apps Builder then generates a complete Forge app, including the HTTP calls, authentication method, and any required configuration fields.

If your app needs an API key or OAuth, the builder automatically generates an admin page where a Jira admin can:

• Follow step-by-step instructions to set up the integration on the external side.

• Enter the required credentials (API key, client ID/secret, OAuth token).

• Provide any resource identifiers the app needs (database ID, workspace, project label).

• Test the connection and save settings.

Once configured, the app is ready to use. Since it runs entirely within Atlassian's Forge platform, all API calls happen inside Atlassian Cloud. Your credentials and data stay within Atlassian's security and permission model.

Real example: Support Ticket Generator built with AI Apps Builder

The AI 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. The answers shaped exactly what got built:

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?	Let me configure the project and issue type in app settings
How will the app connect to Gmail?	OAuth 2.0 (Google sign-in flow)

What got generated automatically:

First, an admin settings page inside Jira (Jira Settings → Apps → Support Ticket Generator — Settings). The page includes 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 a configuration section for the Gmail label and target Jira project.

Second, the app itself appears as a global page called Support Ticket Generator, which you can access from the Jira sidebar under Apps. It shows the Gmail connection status, a Sync Now button, the last sync time, and a table of recently created issues with their key, summary, reporter, and creation date. 

The entire process, including the OAuth flow, admin configuration UI, and Jira issue creation, was built from just one prompt and five answered questions.

Real example: Action Item Extractor built with AI Apps Builder

The AI prompt:

Extract all 'Action Items' from my latest Notion meeting notes and create Jira sub-tasks for them.

You answer four questions, and the result is one issue panel app.

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, I choose each time
Preview action items before creating sub-tasks?	Create them automatically without preview

What got generated automatically:

First, an admin settings page at Jira Settings → Apps → Action Item Extractor Settings. It includes a six-step guide to creating a Notion internal integration, a field for the Notion Internal Integration Token (masked once saved), a Notion Database ID field with a URL hint showing exactly where to find it, and a Test Connection button — with a green "Connected to Notion successfully!" confirmation when credentials are valid.

Second, the issue panel that pulls the latest meeting note from the connected Notion database, displays the extracted action items as a checklist, shows which Jira issue the sub-tasks will be created under, and presents a single "Create Sub-tasks" button. One click creates all three sub-tasks under the current issue.

The app lives exactly where the work happens — embedded in the issue, next to the context it belongs to. No separate page to navigate to.

What else can you connect?

The two examples above cover Gmail (OAuth 2.0) and Notion (API key), but the same pattern works for any supported service.

Here are a few more scenarios teams have described and built:

• Slack → Jira — a command in Slack triggers a deployment, creates a Jira ticket, sends an email, and updates the task status. All automatic.

• Jira status → chain of actions — an issue moves to "Done" and automatically sends a Slack notification, drafts a release note, updates a dashboard, and closes the linked support request.

• Gmail → HubSpot + Jira + Slack + Google Calendar — an incoming enterprise request email creates a HubSpot lead, opens a Jira issue, notifies the sales team in Slack, and books a meeting in Google Calendar.

Each of these starts with one prompt and results in a deployed Forge app.

Why this matters for Jira teams

The value is not just in the connection itself, but also in where the connection lives. Since these integrations are built as Forge apps:

• They appear natively inside Jira, whether in issue panels, admin pages, global pages, or wherever you choose to deploy them.

• They respect standard Jira permissions — the same access controls already in place for the rest of your environment.

• They don't require a separate integration platform or a developer to maintain the connection.

This means you can build and manage integrations without opening a ticket. For product managers and team leads, it means your team's existing tools can show data inside Jira, right where the work happens.

Security: your data stays where it belongs

All external API calls are made from the Forge app running inside Atlassian's cloud. Your credentials and data never leave Atlassian's infrastructure.

The AI's role stops at code generation. It never connects to Jira, never reads your data, and never interacts with the external services your app integrates with. Once the app is deployed, it runs entirely under standard Forge permissions, which is the same model that governs every other app in your Jira environment.

🔒 The AI generates the code. Atlassian Forge runs it. Your data always stays within Atlassian's infrastructure.

Summary

AI Apps Builder lets you connect Jira to external tools like Slack, Gmail, Google Drive, Google Calendar, HubSpot, Notion, and more by simply describing what you want in plain language. The builder handles authentication, creates the configuration UI, and deploys everything as a secure Forge app inside Atlassian Cloud. No integration code and no waiting.

Install AI Apps Builder for Jira and start with an integration your team already needs. Describe the connection and see what the builder generates. You get 100 credits to start. That is enough to build something real.