Jira

Connect Jira Cloud so tickets can start agent work and receive its progress: a requester hands a work item to Kadmo (assigns it, uses Send to Kadmo, or asks for it in a comment that mentions @kadmo or with a label), an agent works it, and the ticket collects status changes and each step's report (one comment by default; see Agent reports). This page covers the two ways to connect, linking a Jira project to a workspace, what agents do on a ticket, requests by comment, 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. See Rules Kadmo creates for you.
• 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.

Requests by comment are not set up for you: they take a rule of their own, which New request rule in the dialog opens filled in. See Requests by comment.

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.

Keep the webhook URL private: see Per-account webhooks.

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. The rules of a link, and when the app path makes one for you, are under Tracker routing.

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.

How a run reports on its ticket, a status per step and each step's report (one comment by default, nothing when the report shape is Quiet: Agent reports), is on What a run writes on the ticket. On Jira:

• A step's status (for example In Progress, In Review) is matched by name (case does not matter) at run time, so it works across workflow schemes. 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 exist before turning it on.
• The run resolves into the status your workflow files under Jira's Done category, whatever it is called, also on Cannot Reproduce.
• When the run stops or pauses, it posts one comment with the reason, the next step and a link to the run (the default; Kadmo's notices change it). A pause's comment arrives about two minutes later, and not at all when the run moved on in that time: see How a notice is delivered. When it escalates, fails or is cancelled, the ticket is not moved and stays where a person picks it up.

An inward is blocked by link is the ticket's blocker in the pool, and higher-priority tickets start first. Kadmo never writes a priority back to a ticket.

Requests by comment

A person can ask for work in plain words on the ticket: write a comment that mentions Kadmo and says what you need, for example @kadmo run a QA pass on the login page. Kadmo reads the request, picks one of the playbooks and workflows the workspace lets a request start, and starts it on the ticket. How it decides, and what its rule offers, is on Kadmo LLM decides; deciding uses your account's AI provider (What it costs).

Set it up

1. On the workspace that the Jira project is linked to, tick what a request may start and choose who may ask: Started by request. An empty list starts nothing.
2. In the Jira dialog, press New request rule. It opens the automations form filled in: comments that mention Kadmo, and Kadmo LLM decides picks what to start. Nothing is saved until you save it. Admins see the link once a Jira credential is saved, on either connection path.
3. Optionally, link people's Jira users and narrow what each may start on the Team page: People.

Write the request

A comment counts as a request when it mentions Kadmo's Jira identity (the Kadmo Agent app user, or your bot user on the API-token path), or when it has @kadmo typed as plain text. The typed form is there because Jira's mention picker often does not offer the app's user; it counts only on a comment that mentions nobody else, since a comment that names a teammate and types @kadmo in passing is talking about Kadmo, not to it. Kadmo reads the comment without the mention; other people's mentions stay part of the request.

Only a new comment is read. Editing an old comment to add the mention starts nothing; write a new one.

How Kadmo answers

Jira gives an app no threaded replies, so Kadmo answers with a new comment, written as the connection's identity. The comment mentions you and ends with ↪ your comment, a link back to the comment that asked. By default you get one when the work starts (▶ with the action, the ticket and the task, run or job it made), when Kadmo needs something from you, and when the work ends (✓ or ✗ with what came of it). The layouts are under The replies; where else a reply can go, and how to turn replies off, is on Kadmo's notices. A run started by a request is reported by the request, so the ticket does not hear the same start or end twice.

Questions and answers

When the request is unclear, Kadmo asks: which of several actions you mean (a numbered list), a missing input by name, or, when the rule confirms first, whether to start (Reply go to start it.). The question waits 24 hours for your next comment on the ticket, and that comment needs no mention:

The question	Your answer
Which one	The number (2, #2 or 2.), or the option's title as written
A missing input	The comment's text is the value
Confirm before starting	go

• Only the person who asked can answer; anyone else's comment is an ordinary comment.
• An answer Kadmo cannot read gets the question once more; after a second miss, the question is let go.
• A new comment that mentions Kadmo is a new request: the waiting question is let go and Kadmo starts over.
• After 24 hours the question lapses; mention Kadmo again.
• An answer is checked against what you may start at that moment, so a list changed in the meantime still applies.

Ask with a label

A rule can listen for a label as well (Issue updated with Label added on the rule; see Automations). Adding that label to a ticket addresses Kadmo the same way: the ticket's summary and description are the request, and the person who added the label is the requester. It fires once, when the label is added. Kadmo answers with a comment as above, and a question is answered by that person's next comment.

What the agent receives

The started work gets the request framed as the requester's, never as system text, ahead of the rule's Hint when it has one. The decision restates the request for the agent and adds nothing:

Request from Ada Lovelace on ENG-12 (Jira comment): "run a QA pass on the login page"

A label request reads (Jira label). The name is the linked person's on the Team page, else the Jira user's display name.

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, write a comment that mentions @kadmo, add the request label — 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, step comments and Kadmo's replies to their requests arrive as normal Jira notifications.

Kadmo recognizes its own edits by their Jira account and skips them; the other reasons an event is skipped are under What happens when an event arrives.

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, and anyone who can comment can ask for work once a request rule listens. 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
Started by request and Who	The workspace's Started by request card	Tick only what a comment may start; choose Listed people only wherever comment access is broad
A person's list, Pause	The Team page's People	Narrow what one person may start; pause an outside person
Confirm before starting	The request rule's options (Automations)	Kadmo replies with what it would start and waits for go from the person who asked

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.
A comment that mentions @kadmo gets no reply	The project needs a request rule (New request rule), and the comment must be new, not edited. A typed @kadmo counts only on a comment that mentions nobody else. The rule's log names the reason for a skip; see The automation page.
Nothing can be started by request in this workspace yet.	The workspace's Started by request list is empty. An admin ticks what a request may start.
You are not on the list of people who may start work here.	Your own list leaves nothing of the workspace's, its actions are switched off, or you are paused. An admin checks your row under People.
Your Jira account is not linked to a person who may start work here.	The workspace allows Listed people only and your Jira user is linked to nobody. An admin links it under People.
ENG-12 is already being worked	A run already drives the ticket; Kadmo does not start a second. Ask again once it has ended.
… could not be started: ENG-12 is already Task #4 in the task pool	The rule pools its work and the ticket has a task in the pool already; the brackets give its status. It runs once approved, and a finished one can be reopened: see Tasks.
That one is not something I can start here.	The action you picked is no longer offered to you; the reply lists what is.
My answer to Kadmo's question was ignored	Only the person who asked can answer, within 24 hours, and the answer must not mention Kadmo, which starts a new request. See Questions and answers.
The pause comment arrives about two minutes after the run paused, or not at all	A pause's comment settles for two minutes and is checked again; when the run moved on in that time it is dropped, while a stop posts at once. See How a notice is delivered.