Your tickets,
run from chat.
Ask the assistant to find issues, create tickets, comment, assign work and move things through the workflow. Jira Cloud stays the source of truth — you just stop tab-hopping to manage it. Every call passes SCRS Gate 1 + Gate 2 and lands in the central audit ledger.
Stop context-switching to Jira
Ask the question. Move the ticket.
You
“What’s on my plate this sprint?”
Other Me
Eight issues assigned to you. Three are In Progress: ENG-142 (SSO login loop), ENG-156 (export CSV encoding), ENG-161 (stripe webhook retries). Five To Do, two of them High priority.
You
“Create a bug in ENG: ‘Password reset email goes to spam on Outlook’ — high priority, assign to me.”
Other Me
✅ Created ENG-247 in the ENG project. High priority, assigned to you, labelled as a bug.
You
“Comment on ENG-142: ‘Blocked on customer confirmation, pinged #support’ — then move it to Blocked.”
Other Me
💬 Comment added. 🔘 Moved ENG-142 via “Blocked”.
You
“Any unresolved issues in ENG created in the last week?”
Other Me
Twelve open issues created in the last 7 days in ENG. Four are Bug, six Task, two Story. Let me know if you want the full list or a breakdown by assignee.
What the assistant can do
Nine tools covering read and write, every one of them SCRS-gated.
Every call is governed
SCRS dual-gate, tier check, audit ledger — on every Jira tool call.
Gate A — Tier Gate
Re-checks the user’s plan at tool-call time, not just at OAuth connect. A downgrade revokes Jira tool access immediately.
Gate 1 — Scope Gate
Users or admins can disable the Projects data collection. When disabled, every Jira tool blocks at call time with a clear message.
Gate 2 — DLP Scan
On create / update / comment, the LLM-synthesised arguments are scanned for PII and secrets before they leave your server. Block-only — the gate refuses to silently corrupt a ticket body.
Audit Ledger
Every call writes a hash-chained row to SCRSAuditLog with gate=tool. Forwards to your SIEM via the same drain the rest of SCRS uses.
Two minutes to connect
-
1
Settings → Integrations → Connect Jira.
-
2
Consent on Atlassian to grant
read:jira-work,write:jira-work,read:jira-userandmanage:jira-project. -
3
Your site is picked up automatically. If you have multiple Atlassian sites, the first one is selected for v1 — reconnect to switch.
-
4
Start asking. Every call is scope-gated, DLP-scanned on writes, and audit-logged.
What’s deliberately not in v1
Four constraints you’ll hit. Here’s why.
Single Atlassian site per connection
If your Atlassian login has access to multiple sites, Other Me picks the first one and tells you which, with clear instructions to disconnect + reconnect to switch. A site picker UI (matching how Xero handles multi-tenant) is planned for v2 — v1 ships when 95% of users have one site, not when 100% have a picker.
Poll-based, not push
The assistant doesn’t subscribe to Jira webhooks — it queries Jira on demand. Ask “anything new in ENG today?” and it’ll check. A “notify me when X changes” model needs a worker path, idempotency, and webhook signing — deferred until enough users ask for it to be worth the complexity.
Jira Software, not Jira Service Management
We can read and write issues in JSM projects (they’re badged [JSM] when you list projects), but JSM-specific workflows — SLAs, approvals, customer-facing request portals, request types — aren’t supported. JSM has a separate REST surface and a different buyer (IT service desk). Different product, different tool set.
No admin-level Jira operations
Creating new projects, adding custom fields, editing workflows — these need the manage:jira-configuration scope, which we deliberately don’t request. An LLM making org-wide schema changes in your Jira is too much blast radius for a chat integration. If you hit a 403, Other Me rewrites the error to say “ask your Jira admin” — you don’t just see a cryptic permission code.
Ship the sprint without switching tabs.
Connect Jira, keep your governance. 7-day business trial, no card on file.
Start my trial