> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cobalt.peoplereign.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Atlassian

> Let an agent search and act across Confluence, Jira, and Jira Service Management on each person's behalf — read pages and issues, file and update work, plus optional admin actions.

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

<Note>
  **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.
</Note>

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

| Module                                       | What the agent can do                                                                                                                                                                                                |
| -------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Confluence**                               | Search pages and spaces, read a page, search comments, check your access to a page, and fetch an attached image or file. **(opt-in)** create a page, update a page (full replace + version bump), and add a comment. |
| **Jira**                                     | Search issues and projects, read an issue, look up a Jira user. **(opt-in)** create an issue, update fields, transition an issue (Open → In Progress → Done), and add a comment.                                     |
| **Jira Service Management**                  | Search and read service requests. **(opt-in)** create a request on an allowlisted service desk and add a comment (the public/private flag is respected).                                                             |
| **Admin actions** (optional, off by default) | Grant an Atlassian product (Jira, JSM, Confluence, and so on) to a user, or add a user to a Jira project with a role — performed under a separate org-admin authorization and audited.                               |

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.

<Steps>
  <Step title="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**.
  </Step>

  <Step title="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).
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Troubleshooting

<Warning>
  **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.
</Warning>

* **"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

<AccordionGroup>
  <Accordion title="Does each person need their own Atlassian login?">
    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.
  </Accordion>

  <Accordion title="Will the agent see pages or issues a person shouldn't?">
    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.
  </Accordion>

  <Accordion title="Can it edit or transition a Jira issue?">
    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.
  </Accordion>

  <Accordion title="Does it work with Jira Service Management?">
    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.
  </Accordion>

  <Accordion title="Can it delete a page or upload an attachment?">
    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.
  </Accordion>
</AccordionGroup>

## Related

* [Integrations overview](/integrations/overview) — how integrations work in
  general.
* [How Cobalt works](/concepts/how-cobalt-works) — where integrations fit.