Jira integration

Jira is on the map, not in the product yet.

When the pipeline needs a human, a Jira issue appears in your project with the context attached.

Not connectable yet

We read from this source rather than publish to it, which means our webhook is no substitute: it delivers outward. This needs an inbound OAuth connection we have not built yet, so there is nothing here to connect today.

How it works

Jira connects through Atlassian's OAuth 2.0 (3LO) flow with granular scopes: write access to create issues and read access to check their status, and nothing broader. When the pipeline hits something that needs human judgment, a page dropped out of the index, two pages cannibalizing the same query, an AI draft waiting for review, we create an issue in the project you chose, typed and labeled the way you configured, with a link back to the full context in SearchHandled.

In the loop, Jira is how human tasks stop living in a dashboard nobody checks. The measure step notices a deindexed page; the fix requires a person, and that person works from a Jira board. Issues arrive where work is already tracked, prioritized alongside everything else, and when the issue is resolved the pipeline picks the thread back up. Atlassian's 3LO consent is site-scoped, so connecting grants access to the one Jira site you approve.

Best forTeams who track work in Jira and want pipeline tasks needing a human to land on the board, not in another inbox.

Setup, step by step

  1. Click Connect on the Jira card, which starts Atlassian's OAuth flow.
  2. Choose the Jira site to connect, since consent is granted per site.
  3. Approve the granular scopes for reading and writing issues.
  4. Pick the project where issues should be created, and optionally the issue type and labels to use.
  5. Trigger the test issue and confirm it lands in the project with the fields you expect.

Best practices

Give pipeline issues a home

A dedicated label or component for SearchHandled issues makes them easy to query, board, and route. Decide the convention at setup so the first real issue already fits your team's structure.

Route by issue kind if it helps

A deindexed page is operations work, and a draft review is editorial work. If different people own them, configure different issue types or labels per event kind so triage happens automatically.

Connect with an account that stays

The connection lives under the Atlassian account that approves it. Use a durable account with permission to create issues in the target project, and reconnect if that account changes.

Resolve issues where you work

The issue links back to SearchHandled for context and action, but its lifecycle belongs to your board. Close it when the work is done, and your normal Jira reporting covers pipeline work like any other.

Known issues

What practitioners actually report, from official docs, issue trackers, and community forums.

3LO consent is site-scoped

Atlassian OAuth apps are authorized per Jira site, so an organization with several sites must grant consent on the specific site where issues should land, and connecting the wrong one puts issues in the wrong place.

How we handle itThe connect flow shows which site you are authorizing and which projects it exposes before anything saves, and reconnecting to a different site is a two-minute redo, not a support ticket.

developer.atlassian.com

Project permissions gate issue creation

If the connecting account lacks create permission in the chosen project, issue creation fails even though the OAuth connection itself is healthy.

How we handle itWe verify create permission in the selected project during setup with a test issue, and later permission changes surface as clear errors in your dashboard rather than silently dropped tasks.

developer.atlassian.com

Questions teams ask

What kinds of issues does SearchHandled create?

Issues for work that needs a person: a page found deindexed, keyword cannibalization detected between pages, and AI drafts awaiting review. Each carries context and a link to the item in SearchHandled.

Can SearchHandled read or modify our other Jira issues?

The scopes cover creating issues and reading issue status, used to track the issues we created. We do not browse your backlog, edit unrelated issues, or touch project configuration.

Will this flood our board with issues?

No. Issues are created for genuine human tasks, not routine events. Publishes, pings, and verifications flow through notifications; Jira only hears about things a person must decide or do.

Not connectable yet

Start with the plan, not the connector.

Build a Growth Map from your site to see the work itself. Approved pages can leave through the export or the webhook today, and telling us Jira matters moves it up the rollout.

Build my Growth Map