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.
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.

​
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.

​
FAQ

Yes — the agent acts as them for every read and write, so they authorize once.
No. Reads and writes run with that person’s own Atlassian permissions; the integration never widens them. Optional space/project allowlists 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.