Customer Service & Helpdesk
Jira Service Management
Rest of world Report an error0–5 in half steps. 5 means the rubric's top anchor is met on the evidence.
by Atlassian Corporation · www.atlassian.com
Report an error on this page Is this your product? →
Read this page as one judge. Each weighs the same scores by what they care about.
The panel's verdict
Jira Service Management scores best on knowledge base & deflection and pricing transparency, worst on omnichannel (a flat 1) and sovereignty. Judges credit AI agents answering employee questions from existing knowledge and AI drafting articles to close gaps, while noting no help-centre structure, versioning or deflection reporting is evidenced. Public per-agent pricing — Free for 3 agents at $0, Standard $20, Premium $51.42 — earns steady marks, though Enterprise is contact-sales and annual-only and nothing maps channels or SLA features to tiers. No support channel is evidenced; queues, routing rules, SLA timers and search are likewise unevidenced. Judges split on ticketing, queues & SLA: some credit a named ticket platform with manual routing, others refuse it where engine mechanics are absent; knowledge base & deflection divides similarly over whether gap-detection counts without workflow proof; sovereignty's 0-1 spread reflects partial credit for documented EU/UK representatives. The sovereignty floor holds regardless: the named controllers are Atlassian Pty Ltd and Atlassian US, Inc., data may transfer globally to wherever Atlassian or providers operate, and residency, subprocessors and jurisdiction are listed as unknown. No flagged split exceeded threshold.
Speaks for it
- AI agents answer employee questions by drawing on existing knowledge.
- AI continually spots knowledge gaps and drafts new articles.
- Three tiers carry public per-agent prices: Free for 3 agents at $0, Standard $20 and Premium $51.42 per agent/month.
- Atlassian acts as processor under a Data Processing Addendum, with GPC opt-out honoured and a portability export available.
- The Atlassian Marketplace offers over 1,000 applications and integrations.
Held against it
- No support channel — email, chat, phone, portal or messenger — is evidenced landing in any queue.
- No queues, routing rules, SLA timers, macros or ticket search are evidenced anywhere in the evidence.
- ML/AI model training is claimed under legitimate interests, and generative AI may be used in responding to support requests.
- Data residency, subprocessor exposure and ownership are listed as unknown while the policy permits transfer to wherever Atlassian or providers operate.
- No documented API, webhooks, SCIM or rate limits appear, and no single integration is named.
Best for
- You run an internal IT, HR or facilities service desk and want AI answering employee questions from existing knowledge.
- You want to start free with 3 agents at $0 and scale on public per-agent pricing.
- You choose integrations by Marketplace breadth and already work within the Atlassian ecosystem.
Avoid if
- You need customer channels — email, chat, phone or messenger — landing in one shared queue with one history.
- You require confirmed data residency or a subprocessor list before signing; both are listed as unknown.
- Your DPO will not accept ML/AI model training on ticket data under legitimate interests.
The scores
Ticketing, queues & SLA
Show reasoningHide reasoning
How this is scored
The engine: how work is routed, prioritised, escalated and measured — and whether an agent can find the ticket they need among ten thousand.
0 — A shared mailbox with labels; no ownership, no status model, no history beyond the thread.
3 — Tickets with assignment and open/closed status, but routing is manual, there are no SLA timers and search covers subject lines only.
5 — Queues with rules-based routing, priorities, a working status model, SLA timers with breach warnings, and full-text search across ticket bodies.
8 — Business-hours-aware SLA policies per queue or customer, escalation chains, macros and triggers, merge and split, and reporting on first-response and resolution time by agent and queue.
10 — The workload is managed rather than merely tracked: capacity-aware assignment, SLA per contract with reporting an account manager could show a customer, audit of every status change, and search that finds the ticket from a half-remembered phrase.
The Support Lead
Nothing in this sheet evidences queues, routing rules, SLA timers, breach warnings or search — the engine a helpdesk lives or dies by. The only escalation evidence is AI grouping alerts into incidents, which is ops firefighting, not SLA management, and every 'AI-powered' claim is marketing I can't check against a live queue. Scored on what's evidenced: a platform claim and use cases, not a ticketing engine. 1
The Agent Advocate
The evidence proves this is a ticket system for IT, HR and facilities teams, but it says nothing a front-liner can use on the hundredth reply: no queues, no SLA timers, no macros, no merge/split, no search — the only 'escalation' evidenced is AI grouping ops alerts into incidents, not a customer-ticket chain. Silence on the engine means I can't credit the engine; a named ticket product with manual-everything is the floor. 1
The Data Protection Officer
The product page sells AI, incident escalation and 'Assets', not the engine — the one escalation quote ('escalate them to an incident') is alert-to-incident, not ticket routing. Nothing in the evidence evidences queues, SLA timers, a status model, macros, or search across ticket bodies; a decade of customers' own words with no evidenced handling mechanics earns a point only for being a service platform at all. 1
The Shop Operator
The evidence evidences no queueing engine at all: no assignment, no status model, no SLA timers, no routing rules, no search — the closest facts are IT-ops alert grouping and escalating alerts to an incident, which is not customer ticketing. For a product claiming 60,000+ customers that silence is glaring, but I score the evidence: barely above a shared mailbox. 1
The Integrator
The evidence evidences only marketing-level engine claims: AI alert grouping and escalation to incidents, and Assets on Standard. Nothing on queues, rules-based routing, SLA timers, business hours, macros or search — the mechanics an 8-anchor needs are entirely silent, which caps this at the manual-routing floor. 1
The Skeptic
The product page talks AI agents, incident summaries and Assets, but never shows a queue, a routing rule, an SLA timer or ticket search; "escalate" appears only as alerts escalating to incidents, not an SLA escalation chain. The engine a buyer needs evidence for is simply absent from the evidence. 1
Channels in one queue
Show reasoningHide reasoning
How this is scored
Email, chat, phone, portal, messengers and social — judged on what actually lands in the same queue with the same history, not on how many channel logos the marketing page carries.
0 — Email only.
3 — Email plus one more channel, but the second lives in its own inbox: no shared history, and a customer who switches channel starts again.
5 — Email, a web form or portal and live chat all landing as tickets in one queue, with the customer's history visible whichever channel they used.
8 — The above plus telephony integration with call logging, at least one messenger (WhatsApp, Signal or similar) with its consent handling stated, and a customer portal where a requester can see their own tickets.
10 — Channel is an implementation detail: every channel including voice and messengers writes to one conversation with one history, agents answer from one screen, and the customer can move between channels mid-issue without repeating themselves.
The Support Lead
No evidence that any customer channel — email, chat, phone, portal or messenger — lands in a shared queue with shared history. The closest facts are social login buttons and Atlassian's own public community forums, neither of which is a support channel my customers would use. 1 3
The Agent Advocate
Not one support channel is evidenced anywhere — no email, chat, phone, portal or messenger is shown landing in a queue, let alone sharing history; the Google/Microsoft/Apple/Slack items are login buttons, not channels. Below even the two-separate-inboxes anchor, because the evidence won't confirm a single inbox. 1
The Data Protection Officer
No channel architecture is evidenced at all — not even email-to-ticket; the evidence's use cases are IT, HR and facilities service desks. The only channel-adjacent fact is SMS originator opt-in data in the privacy policy, which suggests an SMS feature exists somewhere at Atlassian, not that channels share one queue or one history. 1 3
The Shop Operator
Not one channel is evidenced — no email, no chat, no phone, no WhatsApp, no customer portal; the only conversational surface is 'AI agents that draw on existing knowledge' answering employee questions. As the buyer who needs the shop and WhatsApp in one queue with one history, this reads as no evidence of omnichannel at all. 1
The Integrator
No support channel is evidenced at all — not email, chat, phone, portal or messenger; the only request surface shown is AI agents answering employee questions. The SMS references in the privacy policy concern Atlassian's own text messaging, not a JSM channel, so even email-plus-one-in-a-shared-queue is unevidenced. 1 3
The Skeptic
Not one support channel — email, chat, phone, portal or messenger — is evidenced landing in any queue; the Google/Microsoft/Apple/Slack row is account signup, not channels. Missing evidence is information: there is nothing here to unify. 1
Knowledge base & deflection
Show reasoningHide reasoning
How this is scored
Whether the product reduces the number of tickets as well as organising them: public help centre, article workflow, suggestions to agents and to customers.
0 — No knowledge base; answers live in agents' heads and old tickets.
3 — A basic article list, public or internal, with no editorial workflow, no versioning and no link between articles and tickets.
5 — A searchable public help centre with categories, draft and publish states, and agents able to insert an article into a reply.
8 — Article suggestions to the customer before they submit and to the agent while they answer, multilingual articles, review dates that flag stale content, and reporting on which articles deflect.
10 — Knowledge is a managed asset: gaps identified from unanswered tickets, article performance measured against ticket volume by topic, versioned content with approval, and deflection reported as a number the team can act on.
The Support Lead
A knowledge base exists and feeds AI agents, with claims that AI spots knowledge gaps and drafts articles — exactly the claim I'd verify on a Monday, and there's no editorial workflow, versioning, review dates or deflection reporting behind it. Partial credit for the gap-detection ambition; docked because nothing evidences controlled content or deflection measured as a number. 1
The Agent Advocate
There is a real deflection instinct here: AI agents answer from existing knowledge and 'AI is always spotting knowledge gaps and drafting new articles', which is more than a static article list. But no public help centre, no draft/publish or versioning, no review dates, no deflection reporting is evidenced — the gap-spotting promise is only as good as the workflow behind it, which the evidence doesn't show. 1
The Data Protection Officer
'AI agents that draw on existing knowledge' plus AI 'spotting knowledge gaps and drafting new articles' evidences a knowledge base with gap detection — a 10-anchor trait. But nothing evidences editorial workflow, versioning, review dates, multilingual content, or deflection reported as a number the team can act on. 1
The Shop Operator
There is real deflection machinery here — AI answering from the knowledge base and 'spotting knowledge gaps and drafts new articles' — which touches the top of the anchor range. But no public help centre, no editorial workflow or versioning, and no deflection reporting, so I cannot verify the thing I actually judge: that the ticket count falls in December. 1
The Integrator
Evidenced and above a bare article list: AI agents answering from existing knowledge, plus AI spotting knowledge gaps and drafting new articles — a gesture toward gap-driven maintenance. But no help-centre structure, versioning, multilingual, review dates or deflection reporting appears, so it sits between the searchable-centre anchor and the suggestion/reporting anchor. 1
The Skeptic
"AI agents that draw on existing knowledge" and AI "spotting knowledge gaps and drafting new articles" are deflection claims, but they sit alone: no public help centre, editorial workflow, versioning, review dates or deflection reporting is evidenced, and the framing is employee questions, not a customer help centre. 1
Customer data protection
Show reasoningHide reasoning
How this is scored
A ticket archive is personal data written by the data subject. Retention, deletion, access control, subject rights, and what the vendor does with attachments — judged on what executes rather than what is promised.
0 — No retention policy stated, no deletion path, agents all see everything, and no DPA is published.
3 — A DPA on request and coarse roles; deletion is described as something the customer arranges, and there is no stated retention period.
5 — A signable DPA published, configurable agent roles and queue-level visibility, a stated retention period, and deletion of a requester's data that can actually be executed.
8 — Automatic retention rules per queue or data category, attachment handling stated, an audit log of who opened which ticket, documented support for access and erasure requests, and pseudonymisation or redaction of ticket content.
10 — Built for a data-protection audit: retention executed and evidenced per category, field-level redaction, full audit trail, subprocessor list published, and the vendor's own support access to customer instances documented and consent-gated.
The Support Lead
A DPA exists and there's a delete-or-de-identify principle, but no stated retention period, no agent roles or queue-visibility evidence, no audit log and no attachment handling. Worse for my purposes: the policy claims ML/AI model training under legitimate interests and transfers information globally 'to wherever we or our third-party service providers operate' — I could not take that to a customer's DPO. 3
The Agent Advocate
A DPA is referenced with Atlassian as processor, there is a delete-or-de-identify retention principle with backup isolation, a portability export, and GPC honoured. But no stated retention period, no agent roles or queue-level visibility, no audit log of who opened which ticket — and ML/AI model training on data under legitimate interests is precisely what I don't want running over my ticket archive. 3
The Data Protection Officer
A DPA exists ('Data Processing Addendum entered into with those customers') and the retention principle is at least honest about backups — delete or de-identify, or 'isolate it from any further use until deletion is possible' — but no retention period is stated for ticket data, and there is no evidence of per-queue retention rules, an audit log of who opened which ticket, redaction, or attachment handling. Worse, 'machine learning and artificial intelligence model training' runs under legitimate interests and 'generative artificial intelligence' is used in responding to support requests — a vendor claiming a legal basis to train on data, with no documented, consent-gated support access, is exactly what I would refuse in a DPA review. 3
The Shop Operator
A DPA exists, portability is offered, and there is a delete-or-de-identify retention principle — but no stated retention period for ticket data, no agent roles or audit-log evidence, no attachment handling. Worse for a ticket archive, the vendor lists 'machine learning and artificial intelligence model training' under legitimate interests, so the ticket corpus may feed their models. 3
The Integrator
A DPA with processor role stated, a delete-or-de-identify retention principle, GPC honoured and portability are evidenced — better than a DPA-on-request floor. But no retention period, no agent roles or queue visibility, no audit log and no redaction is evidenced, and ML/AI model training sits under legitimate interests; deletion is a principle, not a demonstrable execution. 3
The Skeptic
A DPA exists and deletion/de-identification is stated as a principle, but there is no retention period, no agent role model, no audit log and no attachment handling — while data may be transferred "to wherever Atlassian or providers operate" and ML training runs on legitimate interests. Promise-level, not execution-level. 3
Integrations & API
Show reasoningHide reasoning
How this is scored
The systems a helpdesk has to reach — CRM, shop, order management, identity — and whether the API is documented for building or gated behind a partner conversation.
0 — No API and no named integrations; context is copied in by hand.
3 — A handful of native integrations and a read-mostly API, with no webhooks and no documented rate limits.
5 — Named integrations for common CRM and shop systems, a documented REST API with keys, webhooks for the core ticket events, and SSO.
8 — Maintained bidirectional integrations, customer context from other systems shown inside the ticket, SCIM provisioning, documented rate limits and a sandbox.
10 — A component rather than a destination: versioned API with a deprecation policy, event streaming both directions, an app framework for in-ticket extensions, and integrations the vendor maintains rather than lists.
The Support Lead
A marketplace of 1,000+ apps is more than a handful, but not a single integration is named, and there is no documented REST API, no webhooks, no rate limits and no SCIM anywhere in the evidence. Login via Google/Microsoft/Apple/Slack is consumer sign-on, not the CRM and identity plumbing a support operation needs evidenced. 1
The Agent Advocate
A 1,000+ app marketplace is more than a handful of connectors, but the evidence evidences no documented API, no webhooks, no rate limits, no SCIM and no named CRM or shop integration — a marketplace is a shelf, not a door from my order system into the ticket. I can't build on what isn't documented. 1
The Data Protection Officer
Over 1,000 Marketplace apps is a real ecosystem, but a marketplace proves apps exist, not that a customer can build against a documented surface — no REST API, webhooks, rate limits or SCIM are evidenced anywhere in the evidence. The Google/Microsoft/Apple/Slack signup buttons are consumer login, not enterprise SSO. 1
The Shop Operator
Over 1,000 Marketplace apps gives breadth on paper, but the evidence shows no documented REST API, no webhooks, no SCIM — and critically, no evidence that order or CRM context from other systems appears inside the ticket, which is the whole point for me. Google/Slack login buttons are signup options, not enterprise SSO. 1 3
The Integrator
A marketplace of 1,000+ apps plus Google/Microsoft/Apple/Slack signup is a real catalogue and a login story, but the evidence evidences no documented API, no webhooks, no rate limits, no SCIM and no sandbox — nothing I can build a CRM, shop or identity-provider wiring against. A count of apps is not a contract; per my rules the API surface, being unevidenced, does not exist. 1
The Skeptic
"Over 1,000 trusted applications" on the Marketplace is a logo count: not one integration is named, none stated vendor-maintained, and no documented API, webhooks, SSO, rate limits or sandbox appear anywhere in the evidence. 1
European sovereignty
panel opinion
Show reasoningHide reasoning
How this is scored
Where the ticket archive lives, who the contracting entity is, which subprocessors touch it, and whether vendor support can read customer data. Independently sourced by the sovereignty pipeline; scored here as this buyer weighs it.
0 — Non-EU vendor and contracting entity, hosting unstated or non-EU, subprocessors unnamed.
3 — EU hosting offered as an option while the contracting entity is non-EU, or the subprocessor list is absent.
5 — EU hosting as standard and an EU contracting entity, but parts of the chain — support tooling, analytics, AI features — are non-EU without an explained safeguard.
8 — EU or DACH hosting with a named data-centre provider, EU contracting entity, full subprocessor list published, and any non-EU processing named with its legal basis.
10 — Sovereign end to end and evidenced: vendor, entity, hosting and every subprocessor in the EU, certification published, and a self-hosted or private-cloud option for buyers who need the archive on their own infrastructure.
The Support Lead
Contracting entities are Atlassian Pty Ltd and Atlassian US, Inc., hosting is unstated, the policy says data goes wherever Atlassian or its providers operate, and the subprocessor list is absent entirely — an anchor-zero picture. A single point for the documented EU/UK representatives and stated EEA legal bases, though the 'EU Representative' Atlassian B.V. is addressed care-of San Francisco, which tells me everything. 3
The Agent Advocate
The vendor is US/Australian and the privacy policy stores data 'to wherever we or our third-party service providers operate' — global transfer as a default, with no subprocessor list and no EU hosting anywhere in the evidence. The only EU-facing items are a representative mailbox and DPF-based affiliate transfers; that doesn't tell me where the archive sleeps, and as the buyer who has to answer for it, this is close to the floor. 3
The Data Protection Officer
Non-EU vendor and contracting entities (Atlassian Pty Ltd, Atlassian US, Inc.), hosting unstated, subprocessors unnamed, and a policy that reserves transfer of information 'to wherever we or our third-party service providers operate' with DPF used for intra-affiliate transfers. The EU representative, Atlassian B.V., sits 'c/o Atlassian US, Inc. 350 Bush Street, Floor 13, San Francisco' — a representative that answers in California tells me everything; the evidence's own sovereignty attributes confirm jurisdiction, residency and subprocessors are all unconfirmed. 3
The Shop Operator
Atlassian Pty Ltd and Atlassian US act as controller, information is 'transferred globally to wherever Atlassian or providers operate', and data residency and subprocessors are unknown. The EU representative is Atlassian B.V. — care of a San Francisco address — which tells me everything about where the ticket archive would really live. 3
The Integrator
Controllers are Atlassian Pty Ltd and Atlassian US, the policy states information is collected globally and may be transferred to wherever Atlassian or its providers operate, and the EU representative is c/o the San Francisco office. Hosting, data residency and subprocessors are unknown throughout the evidence — the exact 0-anchor condition for a rest-of-world vendor. 3
The Skeptic
Controllers are Atlassian Pty Ltd and Atlassian US, global transfers are explicit, and the EU representative is Atlassian B.V. c/o a San Francisco address; hosting location and subprocessors are unnamed in every captured page. Non-EU entity, unstated hosting, no subprocessor list — the bottom anchor, and it is earned. 3
Pricing transparency
Show reasoningHide reasoning
How this is scored
Whether a support lead can compute the real annual invoice for their agent count — including the channels and features they actually need — from public pages alone.
0 — No public prices at all; every tier is a sales conversation.
3 — A per-agent headline exists, but the tier where the needed channel or SLA feature begins is unstated, or light-agent and contact limits are not mentioned.
5 — Per-agent prices public for the main tiers with billing period stated, but at least one commonly needed capability (telephony, messengers, SLA policies) sits in an unpriced bundle.
8 — Every tier and add-on priced publicly with per-agent maths, billing period, minimum term and VAT treatment stated; only genuinely custom enterprise work lacks a number.
10 — Complete price computability: a calculator or table producing the annual invoice for a given agent count and channel selection, including usage-metered channels and overage.
The Support Lead
I can compute three tiers myself — Free for 3 agents, Standard $20 and Premium $51.42 per agent/month — which is honest headline pricing. But Enterprise is annual-only behind contact sales, and nothing tells me what channels, telephony or SLA features cost or which tier they start in, so the real annual invoice for my twelve agents isn't computable from these pages alone. 2
The Agent Advocate
Three tiers priced per agent per month with billing stated, even a free 3-agent tier, and Assets mapped to Standard — a fair start. But 'Everything you need to get started' versus 'Scale your service management' tells me nothing about where SLA or channel features begin, Enterprise is contact sales, and VAT and minimum terms are absent; I could not compute my real annual invoice from these pages. 1 2
The Data Protection Officer
Three tiers are public with per-agent maths — $0 for 3 agents, $20 and $51.42 per agent/month — and Enterprise is at least honestly labelled 'Contact sales', billed annually. But nothing maps channels or SLA capabilities to tiers, and there is no VAT treatment, add-on pricing or term statement: a support lead could price the agents but not the invoice. 2
The Shop Operator
Per-agent prices are public — $0 for 3 agents, $20 Standard, $51.42 Premium — which beats a bare headline, but no fact maps channels or SLA features to tiers, VAT treatment and minimum term are unstated, and Enterprise is contact-sales. A support lead can price seats but not the capabilities they need. 2
The Integrator
Free (3 agents), Standard ($20/agent/month) and Premium ($51.42/agent/month) are public per-agent numbers, but Enterprise is contact-sales and annual-only, and nothing in the evidence says which tier carries channels, SLA or the AI features. A support lead cannot compute the annual invoice for the capabilities they actually need from these pages alone. 2
The Skeptic
Per-agent prices are public for Free, Standard ($20) and Premium ($51.42), but Enterprise is sales-only, VAT treatment is unstated, and nothing tells you which tier SLA policies or any channel begins in, or whether the AI features are bundled or metered. A support lead could price the seats but not the invoice. 2
European sovereignty — proven facts
0 of 4 dimensions provenBuilt only from facts shown on the vendor's own pages. A dimension we could not prove is left open, not scored as zero.
| Legal entity | Not determined | — | uncited Report an error |
|---|---|---|---|
| Ownership | Not determined ⚠ unverified | — | uncited Report an error |
| Data residency | Not determined ⚠ unverified | — | uncited Report an error |
| Subprocessors | Not determined ⚠ unverified | — | uncited Report an error |
Where this could be wrong
- Evidence ages. The oldest capture behind this page is from 31 Aug 2026. Vendors change pricing and policies without notice; every fact reflects its source as of the capture date shown in the registry.
- Weak sourcing — Ownership, Data residency, Subprocessors. Not confirmed on the vendor’s own pages as captured.
- AI can misread a source. Extraction and judgement are automated; a citation guarantees traceability, not infallibility. If something here is wrong, say so — no account needed, every report is decided within 5 business days, and accepted corrections are published.
What we left out
A claim that does not survive our checks costs us the claim, not the page. This is what was taken off this one.
- 36 pricing facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 35 product facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 7 compliance facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 integrations facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 2 support facts could not be confirmed on the vendor’s page as captured and were left out of this page and of the panel’s material. Know more? Tell us
- 3 sovereignty dimensions could not be confirmed on the vendor’s own pages and are shown as unknown. Know more? Tell us
- 6 of the readings below were written against an earlier fact sheet — a fact has been corrected, added or pulled since. Until the panel next runs on this product you are reading the older judgement. Know more? Tell us
Sources (15)
The pages every claim on this page was read from — each one checked, dated, and kept verifiable.
- 1 Product page www.atlassian.com Checked 5 Oct 2026 Details →
- 2 Pricing www.atlassian.com Checked 5 Oct 2026 +2 earlier captures: 15 Sep 2026, 31 Aug 2026 Details →
- 3 Privacy policy www.atlassian.com Checked 5 Oct 2026 Details →
- 4 Security / trust page www.atlassian.com Checked 5 Oct 2026 Details →
- 5 Imprint www.atlassian.com Checked 5 Oct 2026 Details →
- 6 Ticketing, queues & SLA — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 7 Ticketing, queues & SLA — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 8 Channels in one queue — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 9 Channels in one queue — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 10 Knowledge base & deflection — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 11 Knowledge base & deflection — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 12 Customer data protection — found from sitemap www.atlassian.com Checked 5 Oct 2026 Details →
- 13 Customer data protection — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 14 Integrations & API — found from sitemap support.atlassian.com Checked 5 Oct 2026 Details →
- 15 Integrations & API — found from sitemap developer.atlassian.com Checked 5 Oct 2026 Details →