Atlassian: Jira and Confluence

Strata connects to Atlassian Cloud through one connection that covers two products — Jira (both Jira Software projects and Jira Service Management service desks) and Confluence. Once an administrator has set it up, you can ask about issues, sprints, queues, service requests, wiki pages and spaces in plain language, and, if your organization allows it, have Strata file an issue, create a page, or add a comment.

Note

Atlassian is Strata's first non-Microsoft connector. Everything Strata reads here comes from Atlassian Cloud rather than from your Microsoft 365 tenant, so the residency and permission questions are answered differently than for Outlook, OneDrive, SharePoint or Teams. See Data residency below.

One connection, two extensions

This distinction runs through the whole page, so it is worth getting straight first.

So a member connects Atlassian once and gets whichever of the two products their organization has enabled for them. There is no separate Confluence connect button, and unchecking Confluence for the organization does not disconnect Atlassian — it withholds the Confluence tools. The stored Atlassian token is only dropped when neither product is allowed.

Neither product is enabled for an existing organization automatically. Both start unchecked; an administrator turns each on deliberately.

What you can ask for

Jira

Strata can search issues with JQL, count them, read a single issue in full, and list Jira Service Management queues. Realistic asks:

• "How many open bugs are in ENG right now, broken down by priority?"
• "Show me everything assigned to me in the current sprint that hasn't moved in a week."
• "Read SUP-4821 and summarize what the customer is actually asking for."
• "Which JSM queues are over their target response time today?"

Confluence

Strata can search pages, blog posts and comments with CQL, read a single page as plain text, and list the spaces available to it. Realistic asks:

• "Find our incident response runbook and tell me who to page for a database outage."
• "What does the ENG space say about our branching strategy?"
• "Summarize the last three retro pages in the OPS space."
• "Which spaces can you actually see?" — useful when you are not sure what an administrator has allowed.

Together, and with everything else

Because both ride the same conversation, you can cross products and mix in the other extensions: "Find the runbook for this error in Confluence, then file a bug in ENG linking to it" uses Confluence and Jira in one answer, and "Pull the open P1s in ENG and email the list to my team lead" finishes in Outlook.

Honest limits worth knowing before you rely on an answer

• Counts from Jira are approximate. Atlassian's search endpoint returns no exact total, so Strata uses a separate approximate-count endpoint and is instructed to say "about". JSM queue counts are the exception — those are exact.
• A newly created issue is not searchable immediately. Atlassian's index can take several minutes to catch up, so Strata reports the issue key it got back rather than searching to confirm its own write.
• Confluence page bodies come back as plain text. Macros are not expanded and the page author is not available, so Strata will not report either.
• Searching Confluence needs a space key, not a space name. Asking about "the engineering wiki" makes Strata list spaces first to find that ENG is the key.

Connection modes

An administrator chooses one of two modes for the whole organization under Settings → Extensions → Atlassian → Manage → Organization settings. The choice applies to Jira and Confluence alike, and it decides whose Atlassian permissions bound what Strata can see.

Each person signs in

Every member connects their own Atlassian account from the Atlassian card in Settings → Extensions. Strata acts as that person, so their own permissions bound every result — a project or space they cannot open in Atlassian is one Strata cannot read for them. This is the default and the narrower of the two.

One organization account

An administrator configures an Atlassian service account (an OAuth 2.0 client-credentials app created at admin.atlassian.com) and everyone works through it. What Strata can reach stops depending on who is asking. Restrict that account inside Atlassian to the projects and spaces Strata should see — Atlassian's own permission engine is a stronger boundary than any filter Strata applies on top.

In this mode there is nothing for a member to connect individually. Attempting it returns "Your organization connects Jira with a shared service account. There is nothing to connect individually."

What each mode means for a scheduled agent

An agent runs on a schedule with nobody signed in, which is where the two modes diverge in practice.

Whether an agent may touch either product is governed separately from the connection mode, in three places: the org and role allowed-extension lists, the per-member agent-extension controls under Admin → Users, and the agent's own capabilities — search_jira and write_jira under Jira, search_confluence and write_confluence under Confluence. The two write capabilities are marked sensitive.

Whether an agent may write is resolved for the agent's owner in both connection modes, using the layers in Who may write. Denying a person writes therefore also stops the agents they deployed — they cannot regain the capability by scheduling a run. And because everything Strata files carries a line naming Strata and the agent, an agent's write is legible as an agent's write in Atlassian's own history.

Setting up Atlassian

Everything in this section requires an administrator with permission to manage organization settings.

1. Enable the extensions you want. Go to Settings → Extensions, open the Atlassian card, then Manage → Organization settings, and turn on the Jira and/or Confluence availability switches. (Direct URL: /settings/extensions/jira/manage.) Roles can narrow the list further, so check that the roles who need them still have them. Without this step nothing else on this page is reachable.
2. Pin the Atlassian site. On that same page, enter your site URL (for example https://your-company.atlassian.net). Strata resolves it to an Atlassian cloud ID and pins to it. One site serves both products. Every save writes an org.jira_config_updated row to the audit log recording what changed — with any service-account secret reduced to [set], never the value.
3. Choose the connection mode. Either of the two above. If you choose One organization account, enter the service account's client ID and client secret. Strata verifies the credential against your site before saving, so a half-configured connector cannot sit there looking fine and failing silently on every agent run. The secret is stored encrypted and never displayed again — changing anything else later does not require re-entering it, but changing the secret does.
4. Configure Jira (in the Jira section): an optional comma-separated project allow-list, for example ENG, SUP, OPS; the writes toggle; and the hourly request cap.
5. Configure Confluence (in its own group on the same page): an optional comma-separated space allow-list and its own writes toggle. Space keys are case-sensitive here, unlike Jira project keys, and the list is capped at 500 keys.
6. Decide about writes — separately for each product. Both are off by default, and turning one on is only the first of three layers. See Who may write before you do.
7. Tell members to connect — only in "each person signs in" mode. They go to Settings → Extensions, click Connect on the Atlassian card, sign in, and approve the requested scopes.

Nothing on this page has a Save button — it auto-saves. Switches and the connection-mode radio commit the moment you click them; text and number fields commit on a short debounce, because Strata resolves the site URL to a cloud ID server-side and a half-typed one would be a real failed request. A status line reads Saving… then Saved, and a toast confirms Atlassian settings saved · Applied to every member immediately. Jira and Confluence are two independent requests, so a Confluence failure is reported on its own and tells you the Jira half did persist.

The site pin is re-checked on every single request, not just at connect time. An Atlassian account accumulates sites as its owner consents to more of them, so without that re-check a member who later connected a personal *.atlassian.net could reach it through Strata. They cannot.

Warning

If no site has been pinned yet, a member trying to connect is told an administrator must choose the site first. The very first connect defines what every future member and every agent can reach, so it is an administrator's action, not a race. An administrator who connects before any site is pinned does define it, and that bootstrap is recorded as org.jira_site_pinned.

Turning Atlassian off for the whole deployment

Strata carries two deployment-wide switches, set on the hosting environment by Kronisys rather than by an administrator inside the app. Each is on unless explicitly set to false or 0.

With a product off, it reports itself as not configured. No tool for it is offered on any surface — chat, scheduled agents, the Teams bot, the public API — an existing connection reads as not connected, and connecting or saving that product's settings is refused. Organizations on One organization account are covered too: that mode mints its own token and never reads the deployment's Atlassian app credentials, so blanking those would not stop it and these switches are the only thing that does.

The allow-lists

Each product has its own. Leaving one empty does not widen anything beyond what the connected account could already see; filling it in narrows Strata further, inside that account's existing access.

The Jira project allow-list bounds four things:

The Confluence space allow-list works the same way for search, page reads and the space listing, and it fails closed: if Strata cannot determine which space a page belongs to, it does not return the page. Reading a page outside the allowed spaces returns "…is in the <KEY> space, which is outside the spaces your organization has allowed Strata to use (<the allowed keys>)."

Be precise about what kind of boundary these are. In "each person signs in" mode an allow-list is a policy — the real boundary is still the member's own Atlassian permissions. In "one organization account" mode you should also restrict the service account inside Atlassian, which is a real boundary. An allow-list is not a substitute for either, and it is not what stops a write.

Writes

Creating issues, creating pages and commenting are off by default, per product. With a product's toggle off, its write tools are never handed to the AI at all — not hidden and refused later, simply absent.

When writes are permitted:

• In chat, you approve every write before it happens. Strata shows you the project, issue type and summary for a new issue, the space and title for a new page, or the target and text for a comment, and waits. Declining stops it.
• A scheduled agent or an API key has nobody to ask, so its writes proceed. This is the same posture as agent email sending. Restrict which agents may write with the write_jira and write_confluence capabilities, role allow-lists, the per-member agent-extension controls under Admin → Users, and the per-member writes settings, which stop every agent that person owns.
• Everything Strata writes is attributed. A trailing line names Strata, and for an agent, which agent and on whose behalf — for example Filed by Strata — scheduled agent "Nightly triage" for alex@acme.com. Atlassian's own author field stays the member or the service account; the line supplies the half Atlassian cannot know.

What Strata can actually write is narrower than it may appear: in Jira it creates issues and adds comments, and in Confluence it creates pages and adds comments. There is no tool that edits an existing page or issue.

Who may write

Turning writes on for a product does not give them to everybody. Whether one person may write is the intersection of three layers, resolved per product on every request:

Alert

Allowed at the role or member layer grants nothing. It means only "this layer does not narrow". The organization toggle is the ceiling, which is why both pickers read Allowed (if the org allows): with the organization's writes off, a role and a member both set to Allowed still cannot write. Denied is the only value at those two layers that changes anything.

In full:

• Organization off — nobody writes, whatever the role and member layers say.
• Organization on — the member writes unless their role or their own setting is Denied. Inherit and Allowed both mean "do not narrow", so they behave identically.
• Unresolvable — a database error, or a member with no matching record — resolves to no writes. The control fails closed rather than guessing.

The two products are independent: denying Confluence writes leaves Jira writes untouched.

Comments on Jira Service Management requests narrow along with ordinary Jira writes. A member who cannot create an issue cannot post an internal note either, whatever Allow comments on service requests is set to.

The member modal shows the resolved answer beneath each picker — Currently enabled for this user or Currently disabled for this user — so an administrator reads the outcome instead of computing it. A change takes effect within about a minute, and every change writes a user.jira_write_access_changed or user.confluence_write_access_changed row to the audit log.

The layers also shape the Atlassian consent screen. A member who may not write is asked for read-only scopes when they connect, even in an organization that allows writes.

Applying one answer to everyone

Each product's writes toggle has an Apply to everyone, with no exceptions option beneath it, visible only once writes are on. With it on, the role and member layers stop applying and the organization toggle becomes the whole answer for every member and every agent of that product. Use it when a compliance owner needs one auditable answer to "who can Strata write as" rather than a per-person one. Turning it back off restores whatever role and member settings were already saved. Turning writes off clears it.

Jira Service Management comments are always internal

Alert

Strata posts comments on Jira Service Management requests as internal notes only. They are visible to your agents and never to the customer who raised the request. There is no setting that makes a Strata comment customer-visible.

This matters because a comment created through Jira's ordinary platform API on a service-desk issue is public by Atlassian's documented default, which emails the reporter and every participant immediately — and the Service Desk API has no comment edit and no delete. Strata therefore routes service-desk comments through the service-desk endpoint with internal visibility sent explicitly, strips @ mentions that could notify independently, and fails closed: if it cannot determine whether an issue belongs to a Software or a Service Management project, it posts nothing.

Commenting on service requests has its own toggle, Allow comments on service requests, which appears only once Jira writes are on and is off by default. Leave it off if you would rather no automated text touched a customer-facing ticket at all.

What Strata stores

In "each person signs in" mode, Strata stores per member: the Atlassian access and refresh tokens (encrypted, scoped to that user's record), their Atlassian display name, email and account ID, and the pinned site and cloud ID. One token row covers both products. In "one organization account" mode it stores the service account's client ID and its encrypted secret on the organization record. Strata never sees an Atlassian password.

Issue and page content is read at question time and used to answer that question. It is not copied into a second store. Strata keeps only short-lived operational caches — which space a page belongs to, and space key lookups — never page or issue bodies.

Key

Strata never indexes Jira or Confluence into the Knowledge Base. The KB ingests files you or an administrator add to it; issues, comments, service requests and wiki pages are read live and are never embedded, cached as KB content, or made searchable outside Atlassian's own permissions.

Disconnecting from Settings → Extensions drops the in-memory session immediately and deletes the stored tokens, removing every Atlassian tool — both products at once — from the AI's toolset on the next chat or agent run.

Audit trail

Every Atlassian write, and every change to the configuration above, produces a Strata audit row in addition to whatever Atlassian itself records:

Each write row carries the acting member, the surface the write came from (chat, agent, API, Teams) and the site. Reads are not audited — they are high volume and leave no trace in your Atlassian. Writes are the opposite: an issue or page is visible to its whole project or space the instant it lands.

Data residency

Atlassian Cloud pins your data to the region you chose when the site was created. Strata's platform database and your organization's Azure AI Foundry are separate infrastructure in their own regions — see Data residency for how those are set.

So an Atlassian question crosses regions by design: the issue or page text leaves Atlassian's region, passes through Strata's application region, and is sent to your organization's Foundry deployment for inference. Nothing about connecting Atlassian changes where Strata's platform data or your Foundry live, and nothing moves your Atlassian data out of Atlassian.

Note

An organization that needs every connector to stay inside the Microsoft boundary should leave both the Jira and Confluence availability switches off on the Atlassian extension page (Settings → Extensions → Atlassian → Manage). Unchecking only one still leaves the other sending content to Atlassian Cloud. Atlassian is not the only non-Microsoft path, though: turning an address into a map location sends that address to Mapbox. That one is governed separately by Address lookup and maps in organization settings, and it is on unless an admin turns it off.

Permissions Strata requests

One consent screen covers both products, and it is assembled from what that member is actually allowed. A Jira-only organization never sees Confluence permissions; a member who may not write is asked only for read scopes.

Jira

Confluence

Shared

Requesting fewer scopes is stronger than requesting them and refusing later: a read-only Atlassian token cannot write even if something further up were to let the tool through.

These administrative scopes are deliberately not requested, in any configuration:

Limits

• Search results are capped per call, with cursor paging for more.
• The AI is told not to page through Jira results to count them, because Atlassian's search endpoint returns no total. It calls the count endpoint instead, and those counts are approximate.
• JQL and CQL must include a restricting clause — Atlassian rejects unbounded queries outright. Strata catches this before the call and asks the AI to add one, such as project = ENG, assignee = currentUser(), or updated >= -30d.
• Jira and Confluence share one request budget, because Atlassian meters its quota per app rather than per customer. An organization's hourly cap defaults to 2,000 requests per hour and can be changed by an administrator on the Atlassian extension page; a platform-wide ceiling of 10,000 per hour applies across all organizations and is consumed first. Leaving the org cap blank uses the default — it does not remove the limit.
• Atlassian applies its own rate limits on top, independent of anything Strata configures.

API access

The public API exposes Atlassian through four scopes on an API key:

Extension scopes augment the chat endpoint, so a key needs chat plus the relevant scope, and the actor the key runs as must have Atlassian connected. confluence.read never implies confluence.write, and neither Jira nor Confluence scopes imply the other product. A write scope is necessary but never sufficient — writes are re-resolved for the key's actor at request time, so a key can never out-scope its own actor. With these four, Strata advertises ten extension scopes in total, alongside Outlook, OneDrive and SQL Server. All appear in the machine-readable spec at /v1/openapi.json. See Extension access for how extension scopes are minted and enforced.

API traffic is unattended, so it carries the same auto-approval posture as an agent: a write proceeds without a confirmation prompt and is stamped Filed by Strata via the Strata API.

What can go wrong

• "Jira is not enabled for your organization." — jira is not in your org's allowed extensions, your role excludes it, or your own account has it denied. Ask an administrator to check all three under Settings → Extensions → Atlassian → Manage and Admin → Users.
• "Your organization has not set up Jira yet." — no site is pinned. An administrator must choose the Atlassian site under Settings → Extensions → Atlassian → Manage before members can connect.
• "This Atlassian site is not authorized for your organization." — the request targeted a cloud ID that is not the pinned one. This is the site check doing its job.
• "That Atlassian account does not have access to your organization's Jira site." — you signed in with an Atlassian account that cannot see the pinned site. Reconnect with the right account.
• "Your organization connects Jira with a shared service account. There is nothing to connect individually." — your org is in "one organization account" mode. You already have access.
• "Creating Jira issues is not enabled for this account.", "Commenting on Jira issues is not enabled for this account.", or "Creating Confluence pages is not enabled for this account." — writes do not resolve on for you in that product. That is the organization toggle being off, or your role or your own account being set to Denied; the wording does not say which, so an administrator has to check all three. See Who may write.
• "…is in the <KEY> space, which is outside the spaces your organization has allowed Strata to read." — the page exists but its space is not on the Confluence allow-list.
• "Your Atlassian connection expired." or "Atlassian rejected the stored credentials." — reconnect under Settings → Extensions.
• "Confluence did not respond in time." — an Atlassian timeout. Retry, and narrow the question if it persists.
• "Jira is disabled on this deployment." or "Confluence is not enabled on this Strata deployment." — a deployment-wide switch is off. No administrator setting can work around it; Kronisys has to turn it back on.
• "…is a Jira Service Management request. Commenting there is disabled for your organization." — Jira writes are on but the separate service-request comment toggle is off. This is deliberate; ask an administrator before assuming it is a mistake.
• "Could not determine whether … belongs to a Jira Software or Service Management project." — nothing was posted. Strata fails closed here rather than risk a comment on a customer-facing ticket.
• "Your organization has reached its hourly Jira request limit. It resets at the top of the hour." — the shared Atlassian budget is spent, across both products. An administrator can raise the org cap.
• "Strata's shared Jira connector has reached its request limit for this hour." — the platform-wide ceiling, not your organization's. Try again shortly.
• "Jira denied this request." — the connected account lacks permission on that project, or, for a JSM queue, lacks a Jira Service Management agent license.
• An agent created an issue or page nobody reviewed — agent runs bypass the chat approval step by design. Grant write_jira and write_confluence only to agents you trust, set the owner's writes to Denied if their agents should never write, and check the jira.issue_created and confluence.page_created rows in the audit log.

Related

• /docs/agents/permissions — how the four Atlassian agent capabilities are granted and governed.
• /docs/admin/org-settings — extension availability, the Atlassian page, and the rest of the organization controls.
• /docs/admin/roles — the role-level Jira writes and Confluence writes capabilities.
• /docs/admin/users — the per-member overrides.
• /docs/admin/audit — reading the audit rows these writes produce.
• /docs/api/extensions — using the Atlassian scopes from the public API.
• /docs/integrations — the extension model in one page.