Skip to main content

​
Atlassian

The Atlassian integration lets an agent work across Confluence, Jira, and Jira Service Management (JSM) while it’s talking to someone — search the wiki, read and create pages, find and file issues and service requests, comment, and transition work. The agent always acts as the asking user, so it only ever sees and does what that person can already see and do in Atlassian. With an extra one-time setup you can also enable a small set of governed, organization-level admin actions (grant a product, add someone to a project).
Atlassian Cloud only. Atlassian Server and Data Center (the self-hosted “classic” products) are not supported. If you connect a classic site the agent reports it can’t reach a Cloud tenant rather than failing silently.

​
What it can do

Capabilities are grouped into modules you turn on per agent. Reads are on by default; every write is off until you enable it, and higher-impact writes ask the user to confirm before they run. Everything the agent does as a user is bounded by what that person can already see and do in Atlassian — the integration never widens their access. Every result links straight back to the page, issue, or request in Atlassian.

​
What it does not do (today)

  • No deletes and no bulk operations — the agent creates, updates, comments, and transitions; it doesn’t delete pages or issues or act on many records at once.
  • No attachment uploads. It can read attachments (to deliver an embedded image or file to the user), but it doesn’t push files into Confluence or Jira.
  • It never invents access. Reads run with the asking person’s own Atlassian permissions. An empty result means “nothing you can see,” not “nothing exists.”

​
Set up read & write access (each person)

Reads (and the as-the-user writes) take about a minute and need nothing in your Atlassian admin — Cobalt hosts the Atlassian sign-in.
1

Add the integration

From your agent, open Integrations, choose Atlassian, and enter your Atlassian Cloud site URL — the acme in acme.atlassian.net (you’ll find it in the address bar when you’re signed into Jira or Confluence). Then pick the modules you want — Confluence, Jira, Jira Service Management.
2

Restrict the reach (optional)

If you want to scope the integration to specific spaces or projects, add a Confluence space allowlist and/or a Jira project allowlist (one key per line — e.g. ENG, DOCS for spaces; INC, REQ for projects). Leave them empty to search everything the asking person can already see. The Jira allowlist applies to both Jira and JSM (service desks are Jira projects).
3

Turn on any write tools you want (optional)

Reads are on by default. To let the agent create or update pages, issues, or requests, switch those tools on individually — leaving them off keeps the integration read-only.
4

Attest to the access requested

Review the access the agent is asking for. The higher-impact scopes (creating and updating content) are flagged. Confirm, name the integration, and save.
5

Let users authorize themselves

The first time the agent uses an Atlassian tool for someone, that person signs in with Atlassian and approves the access. From then on the agent acts as them, and their own Atlassian permissions govern what they see.

​
Set up admin actions (optional)

The admin actions (grant a product, add a user to a project) act at the organization level, so they run under a separate org-admin authorization — not as any individual user.
1

Enable the Admin module

Switch on the Admin module. Its tools stay in an Awaiting authorization state — and the rest of the integration keeps working — until you complete the connect step.
2

Connect as an Atlassian organization admin

Complete the Atlassian Admin connect on the integration’s authorization screen. You sign in once as an org admin to grant the admin access; the token is stored encrypted and never shown again. This authorization is kept entirely separate from each person’s per-user sign-in.
3

Confirm what the agent may do

Admin actions are high-impact, so they ask for confirmation when they run and every one is written to the audit trail.

​
Troubleshooting

Site URL format. Enter your Cloud hostname (acme.atlassian.net) — not a full Jira/Confluence page URL, and not a Server/Data Center address. The field accepts only an *.atlassian.net host.
  • “This looks like a classic (Server/Data Center) site.” Only Atlassian Cloud is supported. There’s no setup that makes a self-hosted instance work.
  • The agent keeps asking someone to authorize Atlassian. They haven’t finished the Atlassian sign-in, or you recently enabled a write tool that needs a new scope — they approve the added access once, then it works.
  • “I couldn’t find that page / issue.” Reads are scoped to the asking person’s own Atlassian access, and — if you set them — to your space/project allowlists. The item may be outside both.
  • A privileged admin action says it needs authorization. The Admin module’s org-admin connect hasn’t been completed (or the token was revoked) — finish the Atlassian Admin connect.

​
FAQ

Yes — for reads and as-the-user writes the agent acts as them, so they authorize once. The optional admin actions run under a separate org-admin authorization instead.
No. Reads and writes run with that person’s own Atlassian permissions; the integration never widens them. Optional space/project allowlists can narrow the reach further.
Yes, when you enable the Jira write tools. Updating fields, transitioning, and commenting are independent switches and off by default; higher-impact writes confirm before they run.
Yes. JSM is its own module — the agent searches and reads service requests, and (when enabled) creates a request and comments, respecting the request’s public/private visibility.
No. This version creates, updates, comments, and transitions, but does not delete records, run bulk operations, or upload attachments. It can read attachments to show you an embedded image or file.