Devin Jira integration

There are two ways to connect Jira Cloud to Devin. Both let people hand Jira work items to Devin and get pull requests back, but they install differently and are triggered differently.

​

Which option should I use?

• Jira Cloud agent features are enabled in your workspace → use the Rovo agent. Devin appears in the assignee picker and in @mentions like any other agent, and reports back on the work item’s agent card. Linking the site also makes its Jira work item events available as triggers for Devin automations.
• Rovo is turned off in your Jira workspace → use a service user. Devin acts through a Jira service account you create, and reports back with comments and remote links.

Both options run regular Devin sessions, work with Devin automations, follow the same requirements, and are billed the same way.

​

Devin automations

Devin automations are the way to start Devin automatically from Jira, and they work with both options. Once a Jira site is connected — linked through the Devin for Jira app or connected with an admin account — its work item events are available as Jira triggers. Pick one when you create the automation:

• Issue created — a work item is created.
• Issue updated — any field on a work item changes; the changed fields are available to the automation’s conditions.
• Label added — a label is added to a work item, one event per label.
• Status changed — a work item’s status changes, or a work item is created with a status.
• Assigned — a work item is created with an assignee, or its assignee changes.
• Comment created — a comment is created on a work item. Comments Devin posts itself don’t trigger it.

Conditions can filter by project, label, status, assignee, epic (the work item’s parent), and summary. When the automation’s session finishes, its final message is posted back on the work item as a comment — from the Devin app for a site linked through the app, or through the service-user connection for a site connected with an admin account. If a site has both connections, each event is delivered once, through the service-user connection.

​

Option 1: Devin Rovo agent in Jira

Devin for Jira is an Atlassian Forge app built on the Rovo agent connector. Once it’s installed and linked, Devin is an agent on your Jira Cloud site: assign a work item to Devin or mention @Devin in a comment, and Devin plans the work, writes the code, opens a pull request, and reports back on the work item.

​

Setup

Setup has two parts: the app is installed on your Jira site, then a Devin admin links that site to a Devin account.

​

1. Install the app on your site

1. A Jira admin opens Devin on the Atlassian Marketplace and installs it on your Jira Cloud site (your-site.atlassian.net).
2. The Jira admin reviews the permissions the app requests and confirms. The app reads and writes work items and comments, reads Jira users and their email addresses (to match them to Devin users), and checks project permissions.

Once the app is installed, Devin appears as an agent on the site, but it can’t accept work until the site is linked to a Devin account.

​

2. Link the Jira site to your Devin account

1. In Jira, go to Settings > Apps and open the Devin page the app adds. It shows “This site is not connected to a Devin account yet.”
2. Click Connect to Devin. A Devin page opens in a new tab. Sign in to Devin if prompted.
3. Check that the Jira site shown is yours, choose the Devin account to link it to, and click Link site.
4. Back in Jira, click Check again. The page now shows the Devin account the site is connected to.

The linked site is listed in Devin under Settings > Connections > Jira as Devin app for Jira · installed from Jira, with a Linked badge. To disconnect, open the site’s Actions menu there, choose Unlink site…, and confirm with Unlink site: Devin immediately stops accepting new work from that Jira site; sessions already running in Devin are not stopped. To relink it, a Jira admin clicks Connect to Devin in Jira again.

​

Triggers

To start Devin automatically from work item events, use Devin automations. There are also two ways to start a Devin session from a work item by hand with the Rovo agent.

​

Assign the work item to Devin

Pick Devin in the work item’s assignee field. Devin starts a session and works on the work item using its summary and description as the task.

• Repeated assignments by the same person within five minutes are treated as duplicates while the task remains active. Assigning the work item again later, or by another person, can start another session even if the first is still running.
• Assigning it to Devin again after Devin has finished starts a new session.

​

@mention Devin in a comment

Mention @Devin in a comment with specific instructions. Devin starts a session that treats your comment as the task and the work item’s description as context. When Devin finishes or stops to ask you a question, it posts its latest message as a comment on the work item, addressed to you. Each comment that mentions Devin starts its own session. To continue a session that’s already running, reply in the agent panel instead.

​

The agent panel

While Devin works, its progress appears in the Jira agent panel on the work item:

• Live status: The agent panel shows live progress from Devin.
• Session link: Devin’s first message is a link to the Devin session in the web app, so you can follow along or take over there.
• Devin’s messages: Devin’s replies are kept on the card as formatted responses with clickable links.
• Questions: If Devin needs your input, the card shows its question. Reply through the task chat in the Jira agent panel; your reply goes to the same Devin session.
• Cancel: Canceling the task from Jira stops Devin and puts the session to sleep.

Only the Jira user who started a Devin task can send it messages or cancel it from Jira. If Devin can’t accept a work item, the card says why — for example, the Jira site isn’t linked to a Devin account yet, your Atlassian account couldn’t be matched to a Devin user, or the organization or your user cannot spend more Agent Compute Units (ACUs) right now. Fix the cause, then assign the work item to Devin again.

​

Pull request links

Devin’s responses in the Jira agent panel include pull request links, and any pull request Devin opened but didn’t mention is listed under Pull requests at the end of the response. For sessions started by an @mention, Devin’s final message is also posted as a comment on the work item; it has the pull request link only if Devin included it.

​

Option 2: Service user in Jira

With this option Devin connects to your Jira site over OAuth and acts through a Jira service account. Nothing is installed in Jira; a Jira admin authorizes Devin from Devin’s settings, and you create a service account in Atlassian that becomes Devin’s identity in Jira — the user you assign work items to and the author of Devin’s comments. Use it when Rovo is turned off in your Jira workspace.

​

Setup

​

1. Connect with an admin account

1. In Devin, go to Settings > Connections > Jira, click Connect account, and choose Connect with an admin account.
2. Sign in to Atlassian as a Jira admin and grant access. Devin registers its webhooks on the site through this account.

Until you add a service account, Devin’s comments post under the admin account that connected Jira, and work items can’t be assigned to Devin.

​

2. Add a service account

1. Configure an Atlassian service account with an OAuth 2.0 credential and the following scopes:
   • read:me
   • read:jira-user
   • read:jira-work
   • write:jira-work
2. Grant the service account Jira application access and permission to browse the relevant projects, add comments, edit and delete its own comments, and link issues. Devin validates the credentials and reports missing permissions when you save them.
3. In Settings > Connections > Jira, open the connection’s menu, choose Add service-account credentials, and enter the client ID and client secret.

From then on Devin’s comments appear under the service account, and assigning a work item to it starts a session. Replacing or removing the credentials keeps your webhooks. Devin normally posts through the configured service account. If its access token cannot be obtained, Devin can fall back to the OAuth token of the admin who connected Jira, so comments may appear under that admin.

​

3. Create an automation

To start Devin automatically from work item events, create a Devin automation with a Jira trigger — see Devin automations.

​

Triggers

To start Devin automatically when work items are created or change, use Devin automations. You can also start Devin on a work item by hand:

• Assign the work item to the service account. Devin starts a session on the work item. Requires a service account.
• Add the devin label. When you add the label to an existing work item, matching is case-insensitive and on whole words: Devin, devin-workshop, and devin-task trigger, while devinworkshop and devin_workshop do not. When a work item is created with labels already set, the label trigger fires only for a label exactly equal to devin (ignoring letter case); devin-workshop does not count.
• @mention the service account in a comment. Devin starts a session on the work item and appends your comment text to the task. If Devin already has an active session for the work item, your comment is forwarded to that session instead of starting a new one.

While Devin has a session for a work item, new assignments and labels on that work item are ignored, and @mentions go to that session. That link lasts 30 days, or until an @mention finds the session has ended or errored.

​

Who the session runs as

Devin matches the Jira user who triggered it to a member of the connected Devin account:

1. First by a linked Atlassian account. Members can link theirs under Settings > Connections > Atlassian, allowing Devin to read Jira as that person.
2. Otherwise by email address: a Jira user whose email matches exactly one member of the account is matched, and the match is remembered.

The session runs as the matched Devin user, in their session list and under their permissions. If no member matches, or the matched member isn’t allowed to use Devin sessions in the organization, the session runs as the shared Devin Jira bot user instead. If Devin can’t pick an organization for the work item, it says so in a comment.

​

Comments and pull request links

When a session starts, Devin comments “Devin is working on your request” and adds a link to the session. When Devin creates a pull request, its URL is added as a remote link on the work item and posted as a comment, along with the link to the Devin session.

​

Requirements

For both options:

• Jira Cloud. Devin for Jira is a Forge app and the OAuth connection uses Atlassian Cloud OAuth, so both need a Jira Cloud site. For self-hosted Jira, see connecting a custom ticketing system through the API.
• A Jira admin to install the app or authorize the OAuth connection, and a Devin admin (someone who can manage integrations for the Devin account) to link the site or configure the connection.
• One Jira site per Devin account. A Jira site can be linked to one Devin account, and a Devin account can be linked to one Jira site at a time. Unlink the current site before linking another.
• Connected repositories, so Devin can push branches and open pull requests. Devin can only open pull requests in repositories it has access to; connect your source code provider first, for example through the GitHub integration.

For the Rovo agent:

• The Devin for Jira app installed from the Atlassian Marketplace, with Jira Cloud agent features enabled in the workspace. See Option 1.
• A Devin Core, Team, or Enterprise plan, with permission to manage integrations, and permission and available usage to start sessions.
• Each person who triggers Devin needs a Devin user. Devin matches the Jira user to a member of the linked Devin account by their linked Atlassian account or by email address. If neither matches, that person can link their account under Settings > Connections > Atlassian. Otherwise, an admin should check that the person belongs to the linked Devin account and that their verified email matches. Work items from Jira users who can’t be matched are declined.
• Permission to start sessions. The matched Devin user must be allowed to use Devin sessions in their organization. For people who belong to more than one organization, Devin first uses their default working organization. Choose it in Settings > Preferences. If Devin cannot select an organization, it asks the person to set a default.

For the service user:

• A Jira service account with the scopes and application access in Add a service account, so work items can be assigned to Devin and Devin’s comments post as the bot.
• A Jira admin account to authorize the connection. Reconnecting it later refreshes the authorization without losing service-account credentials or webhooks.

​

Billing

Sessions started from Jira are regular Devin sessions. They consume ACUs on the Devin organization they run in, at the same rate as sessions started from the web app or any other integration, and count toward that organization’s usage limits. If the organization can’t start new sessions because it has reached its usage limit, Devin declines the work item in Jira — on its card for the Rovo agent, in a comment for the service user. The app is free to install. Devin usage is billed under your Devin plan, and Devin processes Jira content outside Atlassian.