Jira

Blueprintr connects to Atlassian three separate times, for three separate jobs.

Connection	What it reads or writes	Gate
Jira Cloud work items	Work items, saved filters and JQL scopes, on a stratum	Enterprise, continuum_integrations.manage
Jira Service Management Operations	Alerts, Operations teams and on-call schedules, on a stratum	Enterprise, continuum_integrations.manage
Jira follow-up destination	Creates an issue from a stratum	webhook.manage on the organisation, no plan gate

The first two are Continuum Link connectors. The third is a write path and is covered at the end of this page.

Connecting

Both read connectors are created only through Atlassian sign-in. On the New integration form, choosing either provider hides the Name field, the config fields and the secret field, and offers Connect with Atlassian instead. Pasting a token is refused: "Connect this integration through Atlassian sign-in."

After consent you choose an Atlassian site, name the connection, and decide the counts-only setting. Only sites that granted every required scope are offered. If none did, you see "No Jira Cloud site granted the required access. Check the app's permissions and your Jira membership, then reconnect."

Scopes requested are fixed per connection:

Connection	Atlassian scopes
Jira Cloud work items	offline_access, read:jira-work
Jira Service Management Operations	offline_access, read:ops-alert:jira-service-management, read:ops-config:jira-service-management
Jira follow-up destination	offline_access, read:jira-work, write:jira-work

Blueprintr verifies the connection with a read before saving it, and creates no test issue. A connection's site cannot be edited afterwards: the row offers Reconnect with Atlassian rather than Configure, and reconnecting is pinned to the original site.

Counts-only

A checkbox on the site-selection page reads "Import counts and operational state only. Omit work item summaries, alert subjects and query details from blueprint snapshots."

It removes the free text from both the rendered tab and the stored payload:

Object	Removed	Kept
Work item	Key and summary, type, project, parent, components, target versions, related work	Status, status category, priority, resolution, due date, updated time
Query or filter	The JQL, the saved-filter name, and the per-item list	Match count, audience, search consistency, status-category counts
Alert scope	The query text, the matching line, the Operations team, both alert lists	Open, unacknowledged and snoozed counts, coverage, recent history, per-priority counts
On-call schedule	Schedule name and owning team	Counts, timezone, checked-at

Candidate titles also become neutral, such as "Jira work item" and "JSM alert scope", which is what a stratum minted by Scan is named.

Searching Jira Cloud work items

The syntax hint appears on the connection row in settings, not in the stratum search box: "Link a work item, filter:123, epic:PROJ-123, or jql: followed by a query."

What you type	What it does
PROJ-123	Links that work item
A /browse/KEY-123 URL on the connected site	Links that work item
filter:12345	Binds the saved filter by ID. Its JQL is re-read on every refresh, so editing it in Jira changes the tab
epic:APP-42	Work under that epic
jql: followed by a query	That query
Anything else	Searched as a quoted phrase against summaries, never as raw JQL

Queries are capped at 2,000 characters. A link from a different Atlassian site is refused without making a request: "This Jira link belongs to a different site. Choose that site's integration."

A query panel reads at most 250 work items. Past that, the count is a lower bound and the panel says "Showing at most 250 matching work items. Open Jira for the full result."

A bound work item shows work item, type, project, status, status category, priority, resolution, due date and last update, plus parent, components, target versions and related work when present. A missing value reads "Not set or unavailable" rather than a healthy default. Descriptions, comments, assignee and reporter are never fetched.

Searching Jira Service Management Operations

The hint on that connection row reads "Search entity or subject text, query: for an Operations query, team: or schedule:."

What you type	What it does
Plain text	Matches entity or message text
query: followed by an Operations expression	Uses that expression
team: followed by text	Finds an Operations team
schedule: followed by text	Finds an on-call schedule

Queries are capped at 1,000 characters.

An alert panel makes two independent reads on each refresh: current open alerts matching the saved query, up to 500, and a separate newest-15 history page. A large volume of newer closed alerts therefore cannot hide an older open one.

The headline follows a strict order. Any open P1 or P2 makes it critical. An unknown priority or an incomplete read makes it "open alerts · status incomplete". Zero open alerts reads "No open alerts in this query" only when retrieval was complete, every priority was known and nothing else warned; otherwise it reads "No open alerts · recent history unavailable". Partial results never read as an all-clear: the Coverage row says "Partial retrieval; this is not an all-clear" and counts are prefixed "At least".

An on-call schedule panel reports schedule, owning team, counts of current people on call, current team and escalation routes, next people on call, timezone and when it was checked. Individual responder identities and contact details are never returned or stored. Where routing is by team or escalation only, the status reads "On-call routing configured; person coverage unconfirmed" rather than naming anyone as on call.

Freshness and audience

Snapshot	Marked due for refresh after
Jira work item or query	15 minutes
JSM alert scope	5 minutes
JSM on-call schedule	2 minutes

Neither connector sets an audience, so both panels reach everyone who can read the blueprint, including anonymous readers of a public blueprint, embeds and exports. Counts-only is the control for that exposure, and it applies from the next refresh onward rather than rewriting saved snapshots.

Creating a Jira follow-up from a stratum

Configure a Jira destination on the organisation's Settings → Continuum page. Choose + New webhook, set the destination to Jira, then choose Connect Jira account to sign in with Atlassian a second time and grant write:jira-work.

Pick the project, work type and required fields, then use Verify without creating a work item before saving. The work type must have Description on its Jira creation screen, or the destination is refused. Every required field on that screen without a Jira default must also be given a value here.

The Jira follow-up button then appears in the stratum tab strip for an author who can edit the blueprint and holds webhook.manage on the owning organisation. A blueprint with no owning organisation never shows it.

The dialog is titled Create Jira follow-up and asks for a destination, a summary of up to 240 characters prefilled as "Follow up: ", and what needs to happen, up to 12,000 characters. Create Jira issue submits it. Your own submission is the approval step; nobody else reviews it. The text is recorded durably before Jira is contacted, so a retry cannot create a second issue, and reusing a request with different text is refused.

The created issue links back to the stratum. Its key can then be linked through the Jira Cloud connector to follow progress.

New destinations create follow-ups manually only. Automatic creation is opt-in and limited to four events: a blueprint being published, and a workflow run being submitted, approved or rejected.