Jira

Connect Jira Cloud and a ticket becomes the only thing a requester needs: they assign or hand a work item to Kadmo, an agent works it end to end, and the ticket collects status changes and one comment per step. This page covers the two ways to connect, linking a Jira project to a workspace, what agents do on a ticket, and the controls that decide who can start work.

Two ways to connect

Open Integrations → Issue Tracking → Jira. The card offers two connection kinds; both are fully supported.

	Kadmo for Jira app (recommended)	Self-managed API token (Advanced)
Who sets it up	A Jira site admin installs the app; a Kadmo Admin confirms the link	A Kadmo Admin pastes the token; a Jira admin deploys the webhook once
Identity in Jira	The Kadmo Agent app user — created by the install, not a billable seat	A dedicated Atlassian user you create (a billable seat)
Credential	Short-lived app token, renewed by the app — nothing to paste or rotate	An API token you create and rotate by hand
Inbound events	Delivered by the app — no webhook step	A webhook registered with Deploy (Jira-admin only)
Handing over a ticket	Send to Kadmo in the work item's ⋯ menu (every Jira plan, Free included); on Standard and above, Kadmo Agent also appears in the assignee picker	Assign the ticket to your Jira bot user

Without the webhook, an API-token connection still works outward — comments, transitions, reading tickets — but nothing in Jira can start an automation.

Connect with the Jira app

1. In the Jira dialog, press Install Kadmo for Jira. A Jira site admin installs the app on the site.
2. In Jira, the app's Get started page has one button: Connect your Kadmo account. It opens the app on a confirm screen.
3. The confirm screen names the Jira site, its cloud ID, your Kadmo account and Authentication: Jira app (no API token). It also asks When a ticket is assigned to Kadmo:
   • Start automatically (default) — an assigned ticket goes straight into the queue and an agent picks it up.
   • Review each ticket before an agent starts — assigned tickets wait in Tasks until you approve them. Recommended if anyone can edit issues in this Jira site.
4. Press Connect Jira. Only an account Admin can confirm; a User sees a message asking an admin to finish.

The link is single-use and expires ten minutes after it was created. A Jira site is connected to one Kadmo account at a time. The dialog then shows the site, the identity, Token health and the granted scopes; inbound events arrive Through the app.

What connecting sets up for you:

• An automation called Assigned to Kadmo Agent. It pools every ticket assigned to a Kadmo identity and picks the playbook by issue type. It is an ordinary rule — edit, disable or delete it under Automations. Disabling is the lasting opt-out; a deleted rule comes back the next time the site is linked.
• Issue-type routing for common type names the built-in map does not cover. The built-in map sends Bug to Bug Fix, Story and Task to Feature Implementation and Hotfix to Hotfix; connecting adds Defect, Bug Report and Incident → Bug Fix and Improvement, New Feature, Change Request and Sub-task → Feature Implementation where your site has them. Epic and unknown types stay unmapped. Change any of it on the Issue type routing page (see Playbooks); choose Do nothing — ignore, no task to opt a type out.

If the card says the app is installed on your site but not connected to this account, a site admin installed it and nobody pressed Connect your Kadmo account yet — press Finish connecting to open that page, or follow the menu path the card spells out.

Disconnect in the dialog unlinks the account; the app stays installed in Jira. To remove the app itself, uninstall it in Jira (Apps → Manage apps). Automations and workspace bindings stay either way.

Agents on the app path

The app's token works only for Kadmo itself, so it is not given to your agents. If your agents should read and write Jira themselves (for example through the Atlassian MCP tools), give them a self-managed token: add all three of these to Settings → Agents → Global Environment Variables (or to one agent's environment, to override the account value):

JIRA_SELF_MANAGED_URL=your-jira-site-host
JIRA_SELF_MANAGED_EMAIL=bot@yourcompany.com
JIRA_SELF_MANAGED_API_TOKEN=your-atlassian-api-token

A partial set delivers nothing. With all three present, agents — including ones created before you added them — receive the Jira credential and the Atlassian tools together.

Connect with an API token

Open the Advanced · self-managed API token section of the Jira dialog. It is the path to take if you cannot get a site admin to install an app.

1. Create a dedicated Atlassian user for the agent (for example Kadmo Agent) and give it browse, comment, transition and attach permissions on the projects agents will work in. Every transition and step comment then appears under that name, and reporters follow along through Jira's own notifications.
2. Signed in as that user, create an API token at id.atlassian.com → Security → API tokens.
3. Fill in Jira URL (your Jira Cloud site's address, as your browser shows it), Email (the bot user's) and API Token, press Test Connection — it answers Connected as … — then Save. Leaving the token field blank on a later save keeps the stored token.
4. In the Webhook block, press Deploy. Registering a webhook is a Jira-admin action, so the token's user must be a Jira admin, or a Jira admin adds it by hand: Admin → System → WebHooks, the URL the card shows, JQL project = KEY, events issue created, issue updated and comment created.

The webhook URL carries a secret token for your account. Keep it private; if it leaks, press Regenerate, then Deploy again. Test Webhook checks delivery, and Logs → opens the webhook log.

Saving the token also seeds an Assigned to Kadmo Agent rule for this path. It listens for ticket updates where the assignee is your bot user and defaults to hold, so assigned tickets wait in Tasks for approval — an API token is often a person's own account, and starting runs unasked would be a surprise. Change it on the rule.

Saving also delivers the Jira credential and the Atlassian MCP tools to your agents automatically.

Link a Jira project to a workspace

A workspace declares the Jira project it serves, so a ticket routes to the right repository and agents. Open the workspace's edit page and use the Work intake card: the Jira project field lists your Jira projects once Jira is connected (see Workspaces).

Rule	Behavior
Shape	One Jira project per workspace, one workspace per project key in the account
Key	Jira's uppercase key, starting with a letter: letters, digits and underscore
Effect	A run started from a ticket in that project runs in the workspace's repository, on the workspace's agents
Not linked	Tasks created in the workspace are internal, keyed with its task key prefix

On the app path this is often automatic: the first assigned ticket from a project links that project to your account's only unlinked workspace — but only when there is exactly one such workspace. With two or more, nothing is guessed; set the field by hand.

Linking a project is also a trust decision: it is, in effect, permission for that project's tickets to start work.

What agents do on a ticket

A Jira automation with a playbook action runs a whole playbook on the triggering ticket. By default it pools the ticket in Tasks, where it runs once approved and once its in-pool blockers are done; Run immediately is the opt-out.

Moment	What happens in Jira
A step starts	The ticket moves to that step's status (for example In Progress, In Review), when status sync is on
A step finishes	The agent posts one comment with what it did, the evidence and a verdict; Kadmo reads that comment to decide the next step
The run stops or pauses	One comment with the reason, the next step and a link to the run
The run resolves	The ticket moves to the status your workflow files under Done (also on Cannot Reproduce)
The run escalates, fails or is cancelled	No transition — the ticket stays where a person picks it up

A step's status is matched by name (case does not matter) at run time, so it works across workflow schemes; the final move targets Jira's Done category, whatever your workflow calls that status. Status sync is best-effort: a status the project does not have is skipped and never fails the run, so check that the names your playbook uses (for example In Progress, In Review) exist before turning it on.

Kadmo also respects Jira's structure: an inward is blocked by link becomes a task dependency when the blocking ticket is in the pool too, and higher-priority tickets start first. Kadmo never writes a priority back to a ticket.

The Jira-native operating mode

Put together, the requester never opens Kadmo:

1. They file a ticket and assign it to Kadmo — or use Send to Kadmo — or a rule of yours matches it.
2. The ticket lands in the workspace bound to its project and runs through the playbook its issue type maps to.
3. They follow progress by watching the ticket: status changes and step comments arrive as normal Jira notifications.

Kadmo never re-triggers itself: its own edits are recognized by their Jira account and skipped, and a ticket that already has an active run never starts a second one.

Who can start work

Ticket text is untrusted input: anyone who can edit an issue can put instructions in front of an agent by assigning it. Use the controls in order of strength:

Control	Where	Use it
Approval	The rule's Approval setting (chosen on the confirm screen for the app)	Hold for review wherever edit access is broad
Project binding	The workspace's Work intake card	Link only the projects whose tickets agents should pick up
Project filter	The rule's trigger filters (Automations)	Confine a rule to one project
Per-project intake and auto-assign	The Jira app's project settings	Turn intake off for projects external reporters file into; leave auto-assign off where edit access is broad

Troubleshooting

Symptom	Cause and fix
Assigning to the agent does nothing	On a hand-built rule, tick Issue assigned (Jira app only) — it is not in the default event set. On the app path, check the card is connected and not installed, not connected.
Jira returned 401 on Test Connection	Wrong email or token. Create a new token as the bot user and save it.
Deploy fails	Registering a webhook needs a Jira admin. Have one press Deploy or add the webhook by hand.
The Jira app delivers its own events — no per-account webhook is needed	You are on the app path; there is nothing to deploy.
Matched, but no run started	The ticket already has an active run, it is waiting for approval or a blocker in Tasks, or its issue type is mapped to skip.
Runs land in the wrong repository	Link the project to the intended workspace on its Work intake card.
A step paused with no verdict	The agent posted no comment for that step; Kadmo pauses the run for review rather than guess. Open the run in the app and decide how it continues.
Agents cannot reach Jira on the app path	Add the three JIRA_SELF_MANAGED_* variables described above.