How to Connect Devin AI to Jira

Official Cognition docs document four distinct ways to start a Devin AI session from a Jira issue: assign the ticket to Devin, add a playbook label, add a devin label, or @mention Devin in a comment [Cognition Devin Docs]. Most third-party writeups stop at "assign the ticket." That single path is real, but it is only one of the four, and it always runs the default playbook. Teams that never configure playbook labels, never try scoping-only mode, and never attach a service account end up with sessions that feel random, comments that look like they came from a human admin, and no safe path to automatic pickup.

The Devin AI Jira integration turns Jira issues into Devin sessions so tickets can become planned work and pull requests, with updates posted back to the issue. Cognition ships it as a native project-management integration next to Linear, not as a side script you maintain yourself. In the broader integrations surface, Devin also connects to source control (GitHub, GitLab, Bitbucket, Azure DevOps) and supports MCP connections for external tools. Jira is the intake layer. Source control is where code lands. Your team still needs a place for specs, design dumps, acceptance notes, and review artifacts that do not belong in the repo.

This guide stays close to official setup and configuration steps:

1. Connect Jira from Devin settings and grant access
2. Prefer a service account so comments use a bot identity
3. Configure playbook labels and a default playbook
4. Choose direct session creation or scoping-only mode
5. Trigger work with assign, playbook label, devin label, or @mention
6. Optionally add automation triggers and enterprise project mapping

If you only need the short answer: open Settings → Connections → Jira, click Connect, finish the Jira permission grant, set playbooks, then assign a ticket to Devin or label it. The rest of this article is the production version of that path.

You connect from the Devin side, not by hunting for a Devin app inside every Jira admin screen first. Official setup is three moves.

Connect steps

1. In your Devin account at app.devin.ai, open Settings → Connections → Jira and click Connect.
2. You are redirected to Jira to review permissions and grant Devin access.
3. Back in Devin settings, configure playbook labels and, if you want automatic pickup, automation triggers.

After connect, Cognition recommends connecting a service account so Devin's comments appear as a bot identity instead of your personal admin account. Skip that only for a private sandbox. On any shared Jira project, personal-account comments create confusion in history and in notification routing.

What "connected" actually means

Once the integration is live, Devin can create sessions from issues, post progress back on the ticket, attach PR URLs as remote links, and keep a session link on the issue so humans can open the live run in the Devin web app. Follow-up work stays on the same ticket: mention @Devin in a comment to send more instructions or questions into the existing session when one already exists for that issue.

Devin does not replace your engineering process. Branch protection, code review, and merge rules still live on the source-control side (GitHub, GitLab, Bitbucket, or Azure DevOps, depending on what you connected). Jira is the work-item spine. Devin is the agent that can take a well-scoped ticket and push toward a PR.

Enterprise note before you test

For enterprise deployments with multiple Devin organizations, admins can map Jira projects to specific Devin organizations. Official docs state that a mapping is required for the Jira integration to work in those enterprise setups. If tickets never start sessions in a multi-org enterprise environment, check project mapping before you re-auth the OAuth app.

Official docs list four trigger paths. Use the one that matches how your team already moves tickets. You do not need all four on day one.

1. Assign the ticket to Devin Assign the issue to the Devin service account in Jira the same way you assign work to a person. Devin starts a session using the default playbook configured under Jira integration settings. This path is best for a single "bot assignee" workflow where every Devin-bound ticket should run the same playbook.

Practical tip: make the assignee identity the service account, not a human admin who once clicked Connect. That keeps board filters, workload views, and "who owns this" answers honest.

2. Add a playbook label

Add a playbook label such as !plan, !implement, or !triage to the ticket. Devin starts a session with the playbook that matches that label. Labels come from the playbook labels list in integration settings. You must create the matching labels in your Jira project yourself. Copy the exact label name from Devin settings into Jira.

Playbook labels are the main gap in most third-party posts. They are also the cleanest way to give different ticket types different agent behavior without writing custom automation first. Planning tickets get !plan. Implementation tickets get !implement. Support-style tickets get !triage once you define that playbook and its macro.

3. Add the devin label

Add the devin label to any issue (create the label in the project first if needed). Devin uses the default playbook, same as assign-to-Devin.

Matching is word-boundary based and case-insensitive. Official docs call out that labels containing devin as a standalone word trigger the integration: devin, Devin, devin-workshop, devin-task. Labels where "devin" is glued into a larger word, such as devinworkshop or devin_workshop, do not trigger. That detail matters when you invent naming schemes for workshops or internal tooling.

4. @mention Devin in a comment

Mention @Devin in a ticket comment and write specific instructions. Devin starts a session and uses your comment as the task instruction. A playbook is not applied on this path. If a session already exists for the ticket, the message is forwarded to that session instead of spinning up a second one.

Use @mention when the ticket already has a human owner, the board does not want a bot assignee, or you need a one-off instruction that should not load the default playbook. It is also the right path for mid-flight course corrections once a session is running.

Quick chooser

Same playbook every time, clear bot ownership: assign to Devin

• Different playbooks by ticket type: playbook labels (!plan, !implement, and so on)
• Default playbook without changing assignee: devin label
• One-off instructions or follow-ups: @mention in a comment

Keep Devin ticket artifacts in one shared workspace

When Jira starts the work and Devin opens the PR, park specs, review packs, and handoff files in a Fast.io workspace with MCP access, version history, and Intelligence Mode search. Every org starts with a 14-day free trial.

Start 14-Day Trial

Configuration is where the integration stops being a demo and starts matching how your team writes tickets.

Playbook labels and the default playbook

Playbook labels map Devin playbooks onto Jira labels. When you add a playbook in Jira integration settings, its macro (for example !plan) becomes a label you can put on issues. Only playbooks that have a macro can be added. Remove a playbook from the list when you no longer want its label to trigger sessions.

One playbook is marked as the default. Assign-to-Devin and the bare devin label both use that default. Playbook labels override it for that ticket. If default and labeled behavior feel identical in testing, you probably never set distinct macros, or you never created the matching labels inside Jira.

Operational checklist:

• Define the default playbook for "generic implement this ticket" work
• Add extra playbooks only for workflows you will actually label
• Create the labels in each Jira project that will use them
• Document the label set for PM and eng so people do not invent near-miss names

Session mode: direct creation vs scoping only

The session mode toggle controls what a trigger does.

• Direct session creation (enabled by default): Devin creates a full session, works the issue, and posts updates back to Jira.
• Scoping only: Devin analyzes the ticket and posts a scoping comment with a summary, implementation plan, and confidence estimate. A link in that comment lets a human start a full session manually.

Scoping-only mode is the safest onboarding mode for teams that still distrust fully autonomous pickup. Use it when ticket quality varies, when cost control matters, or when you want a human gate between "Devin looked at this" and "Devin is changing code." When ticket quality and review discipline are solid, switch to direct session creation for the queues you trust.

What Devin posts back

While a session runs, the ticket stays the status surface for people who live in Jira:

• PR links land as remote links on the issue and as comments when Devin opens a pull request
• Session links point into the Devin web app for live progress
• Follow-up @mentions send more instruction into the same session when one already exists

That loop is enough for many teams. It is not a substitute for storing long-lived product context next to the work. Ticket comments rot. PR descriptions get squashed. Specs and decision notes need a durable home outside the issue thread.

Manual assign and label triggers are enough for a pilot. Production usually adds three more pieces: automation triggers, a service account, and (for multi-org enterprise) project mapping.

Automation triggers

Automation triggers start Devin when a ticket matches conditions, without a person assigning or labeling by hand. Official configuration options are:

• Projects: only tickets in selected Jira projects
• Labels: only tickets that carry specific labels
• Statuses: only tickets that reach a status such as "To Do" or "In Progress"
• Playbook: optional playbook for sessions started by the trigger

Triggers use edge detection. They fire when a ticket moves from not matching to matching. They do not fire for tickets that already match when you save the rule. That design prevents a surprise backlog flood on day one, but it also means existing "Ready for Devin" tickets will not auto-start until something changes (status flip, label add, and so on). Plan a one-time manual pass for the current queue, or intentionally re-touch tickets you want the agent to pick up after you enable a rule.

Good first automation: one project, one status transition into "Ready for agent," one explicit playbook, no org-wide catch-all.

Service account best practices

After you connect Jira with an admin account, connect a service account with OAuth client credentials so comments use a dedicated bot identity.

Official scope set for the Atlassian OAuth service account (classic scopes):

• read:me
• read:jira-user
• read:jira-work
• write:jira-work

The service account also needs the User application role for Jira. In Atlassian Admin, open Directory → Service accounts, select the account, use Allow access, and set the Jira role to User. Without that role, the service account cannot reach Jira resources even if OAuth credentials look correct.

Then in Settings → Connections → Jira, choose Connect service account and enter the client ID and client secret.

Why this is not optional on a real board:

• Comment history stays attributable to the agent, not the engineer who installed the app
• Notification noise for that human admin drops
• Assign-to-Devin has a stable identity to point at
• Audit and compliance conversations get simpler because bot actions are labeled as bot actions

Enterprise: map Jira projects to Devin organizations

Enterprise customers with multiple Devin organizations can map each Jira project to a specific Devin org. Official docs state that mapping is required for the integration to work in those setups. Treat mapping as part of install, not a later polish step. Wrong or missing maps present as "connect succeeded, nothing happens when we assign tickets."

Where ticket outputs and supporting files should live

Code still belongs in the connected git host. Many teams also drop temporary notes in Jira comments or attach PDFs to the issue. That works until search fails, permissions get awkward for external reviewers, or agents need a shared place for multi-file context.

Alternatives people already use:

• Local disks and shared drives for drafts that never leave the laptop or the office share
• Object storage such as S3 for bulk blobs with no product UI
• Google Drive or Dropbox for human-friendly folders that are weak as an agent API surface

For agentic teams that need a shared workspace layer next to Devin AI sessions, Fast.io is a strong option. Humans and agents share org-owned workspaces with per-file version history, granular permissions, and an append-only audit log. Enable Intelligence Mode so files are indexed for hybrid search (full-text, semantic, and metadata). Agents can work through Fast.io's consolidated MCP tools over Streamable HTTP at /mcp or legacy SSE at /sse. See the storage for agents guide for how that workspace layer fits next to coding agents. When a contractor agent finishes staging specs or review packs, ownership transfer hands the workspace to a human while the agent can keep admin access. Plans run on a paid org subscription with a 14-day free trial that requires a credit card: Starter $29/mo, Business $99/mo, Growth $299/mo.

That layer does not replace the official Devin AI Jira integration. It holds the durable files around the ticket while Jira remains the system of record for status and Devin remains the coding agent.

Treat the first week as controlled experiments, not a full board automation.

Day 1: connect and identity

1. Connect Jira from Devin settings and confirm the connection is active.
2. Create and attach the service account with the documented scopes and Jira User role.
3. Confirm comments from a test session appear under the bot identity.

Day 2: playbooks and a single trigger

1. Set one default playbook for implementation work.
2. Add one extra playbook with a macro such as !plan if planning tickets are common.
3. Create the matching labels in one Jira project.
4. Run one assign-to-Devin ticket and one playbook-label ticket. Compare comments and PRs.

Day 3: scoping mode and quality gates

1. Flip session mode to scoping only for a project with noisy tickets.
2. Read the scoping comments for summary quality, plan usefulness, and confidence estimates.
3. Only promote direct session creation for queues where scoping comments look consistently sound.

Day 4: automation with edge detection in mind

1. Add a narrow automation trigger (one project, one status or label, explicit playbook).
2. Move a ticket across the edge so the rule fires. Do not expect already-matching tickets to start on their own.
3. Watch for duplicate sessions if people also assign and label the same issue. Teach the team one primary trigger per queue.

Day 5: enterprise mapping and artifact home

1. If you run multiple Devin orgs, finish Jira project mapping before scaling volume.
2. Decide where non-code artifacts live: issue attachments, a wiki, object storage, Drive, or a shared intelligent workspace such as Fast.io for agent-readable files with version history and search.
3. Document the four trigger paths for the team so "assign jira tickets to devin" is not the only muscle memory.

Failure modes to check first

Nothing starts on assign: wrong assignee identity, missing default playbook, enterprise mapping missing, or connection not actually active

• Label does nothing: label not created in Jira, typo vs settings macro, or devin glued into a non-boundary word like devinworkshop
• @mention starts the wrong kind of work: expected, because comment triggers skip playbooks; put instructions in the comment or use a playbook label instead
• Automation silent on old tickets: edge detection; change status or labels to cross the threshold
• Comments look like a human admin: service account not connected or missing Jira User role
• PR never appears on the issue: source-control integration not connected, or the session never opened a PR; check the session link on the ticket first

Keep Devin AI explicit in runbooks: it is the agent that takes Jira work into sessions and pull requests. Jira stays the queue. Git stays the code store. A shared workspace is optional infrastructure for everything else the ticket needs.