Issue tracking: the fix ticket, and only that
With a tracker connected, every patch also exists as a ticket, so change management has a paper trail in the system it already watches. Sarcio needs only enough Jira access to create those tickets, comment on them, and transition them, in the spaces you give it.
Recommended: a service account or bot user
The Jira connection is a workspace connection, managed only by workspace admins. Every ticket and comment appears as the account behind it, so give Sarcio an Atlassian identity of its own: a service account, or a dedicated bot user, with access to only the spaces Sarcio files into. When an admin saves its token, Sarcio calls GET /rest/api/3/myself (identity only; a scoped service account token needs read:jira-user for it, and saves without it) and badges the connection Bot token for a service account or Personal for an ordinary account. Service account tokens are called through Atlassian's api.atlassian.com gateway, which Atlassian requires for them; Sarcio finds that on save.
Jira Cloud
An API token for an Atlassian service account, or for a dedicated bot user, with access to only the spaces Sarcio uses.
| Scope requested | What it grants, and why | Access |
|---|---|---|
Browse projects | See the spaces fix tickets file under, with their issue types and transitions. | Read |
Create issues | File the fix ticket when a patch drafts or goes live. | Write |
Add comments | Comment at each milestone: live, PR opened, expiring, retired. | Write |
Transition issues | Move the ticket (e.g. to Done) when the fix PR merges. | Write |
Browse users and groups (global) | Optional: find an approver by email so the go-live comment @mentions them. Without it approvers are named instead. | Read |
Tickets and comments come from that account, not a teammate. On save, Sarcio calls GET /rest/api/3/myself: accountType app (a service account) is badged Bot token, and atlassian (an ordinary account, a bot user included) is badged Personal. Service account tokens are scoped (read:jira-work, write:jira-work, plus read:jira-user for the owner check and mentions) and Atlassian requires them to call https://api.atlassian.com/ex/jira/<cloudId>, so Sarcio finds which address accepts the token when you save it. It also checks the Browse users permission and each configured project. The API token is envelope-encrypted at rest; the account email is stored with it as the sign-in name. Approvers' emails are only lookup keys and are never written into a comment.
Personal connection: Connect Jira (quick start)
Connecting over Atlassian OAuth (3LO) acts as the consenting user. Tickets and comments appear as them, the connection stops working if they leave, and it is badged Personal. Sarcio files into the first Jira site the grant reaches, so authorize with an account that can reach only the site you want.
Jira Cloud
Connect Jira over OAuth (3LO). Sarcio acts as the consenting user.
| Scope requested | What it grants, and why | Access |
|---|---|---|
read:jira-work | Read projects and issue metadata so fix tickets land in the right project with the right fields. | Read |
write:jira-work | Create the fix ticket, comment at each milestone, and transition it when the permanent fix merges. | Write |
offline_access | Obtain a refresh token so the connection keeps working without you re-authorizing. | Token |
Tickets and comments appear as the person who consented, and the connection is badged Personal. Sarcio files into the first Jira site the grant reaches, so authorize with an account that can reach only the site you want. The access token and rotating refresh token are envelope-encrypted at rest; the Jira site id is stored alongside. Only metadata you already see in the dashboard crosses over — captured console, network, and screenshot payloads never cross into Jira.
Ticketing is best-effort by design: a tracker outage never blocks or slows a patch action. And the data boundary is strict — commit messages, branch names, and PR titles follow your convention so Jira auto-links everything, but the captured console, network, and screenshot payloads behind a report never cross into your tracker. When a patch goes live, the comment names its approvers, for example Approved in Sarcio by @Ada Lovelace and Bo K.: an @mention when the approver linked their Atlassian account, or the connection can browse users and exactly one Jira account matches the approver's email; their name otherwise. The email is only a lookup key and never appears in the comment. A linked account stores no token; if an admin allows acting links, an approver can opt in to posting that go-live comment as themselves.
See it from the inside.
Spin up a workspace and every one of these connections is a click away — with the exact scopes shown before you approve them.
Create a workspace