Continuum Integrations

Continuum connects a diagram or a stratum to the systems it describes, so the drawing can be regenerated and the detail on it comes from the source.

Continuum Cloud, Continuum Link and Continuum Local are licensed separately and do different things.

	Continuum Cloud	Continuum Link	Continuum Local
Connects to	AWS and Azure	28 monitoring, ITSM, on-call and uptime platforms	7 on-premise monitoring systems
Puts data on strata	Yes	Yes	Yes
Draws on a canvas	Yes	No	No
Licence	Teams	Enterprise	Enterprise
Permission	cloud_connections.manage	continuum_integrations.manage	continuum_integrations.manage
Where credentials sit	A read-only role in your own account	Encrypted by Blueprintr	On your own agent, never sent to Blueprintr

Continuum Local is the on-premise half of Continuum Link rather than a product of its own. It shares Link's gate and its connectors.

Choosing one

Generate a diagram from an AWS account or Azure subscription with Continuum Cloud.

Put live operational data beside something already drawn with Continuum Link.

Reach a monitoring system that cannot be called from the internet, or keep its credentials inside your network, with Continuum Local.

What Continuum does not do

Scheduled polling is unavailable on every plan. Continuum Cloud syncs when you ask it to, and a Continuum Link tab refreshes when an editor presses refresh. Nothing updates on a timer.

Blueprintr evaluates no conditions, holds no thresholds and pages nobody. It reads state from the systems that do.

Before you publish

Both products write into strata, and a stratum follows the blueprint's own visibility. On a public blueprint, that means anonymous readers.

Continuum Cloud strata carry account ids, resource ids, regions, addresses and a raw payload. Continuum Link panels are reader-visible for every connector except Datadog, LogicMonitor, Auvik and Rootly, which default new connections to blueprint editors.

Review what a diagram carries before publishing it publicly. Changing an audience later applies to subsequent refreshes and cannot recall copies already shared.

Continuum Cloud reads an AWS account or Azure subscription and draws what it finds onto a Vellum canvas, with each resource's detail attached as a stratum.

It needs a Teams licence and cloud_connections.manage on the organisation or team that owns the connection. Free and Premium have no Continuum surface, and creating a connection below Teams refuses with "Continuum is a Teams-plan feature."

What it produces

One Continuum tab in a blueprint, backed by a private Vellum document named after the tab.

Artefact	What it holds
Shapes on a canvas	Resources the layout draws, nested inside the boundaries in the source: accounts, regions, VPCs and subnets, resource groups
A stratum per resource	Identity, configuration, per-type tables, tags, related strata, and the raw payload in a collapsed Raw data disclosure
A poll run per scope, per sync	What was found, what changed, and every read that failed

Resources that describe relationships rather than occupy space, such as route tables, security groups, network ACLs, IAM and KMS, get a stratum with no shape. They are filed under a (Context) folder in the Files sidebar and cross-linked from the resources they affect.

A resource collapsed into a group shape, such as Auto Scaling members or a Lambda name family, also gets a stratum with no shape of its own. Those sit alongside the drawn resources rather than under (Context).

What is discovered

Continuum discovers 77 AWS resource types and 75 Azure resource types. Of those, 53 AWS types and 52 Azure types are drawn as shapes by default. The rest are read for their relationships, for the containers they define, or for stratum context.

Permissions

Every action on the settings page checks cloud_connections.manage on the owning organisation or team. Built-in owners and admins hold it; anyone else needs it granted through a custom role.

integration.manage is a different permission, for embedding Blueprintr content in SharePoint and Confluence. Holding it opens the settings page but grants nothing in Continuum.

Limits

	Team	Enterprise
Cloud connections per owner	3	Unlimited
Scopes per diagram	3	Unlimited

Team settings → Plan & limits also shows Resources per integration as 200 on Teams. Nothing enforces that figure today, and a sync is not truncated at 200 resources.

Syncing is manual

Open the tab's settings cog and choose Sync now to re-discover every scope, or Re-sync one scope from Settings….

Views on the same canvas

The canvas carries a View switcher. Base topology is the default; the others recolour the same shapes to answer one question each: Routing, Security groups, Cost (est.), IP addresses, Public exposure, Availability zone and Tag coverage. Views authored on the diagram appear in the same list.

Setting one up

Connecting an AWS account covers the role, the verify step and the first scan.

Connecting Azure covers the app registration and the Reader grant.

Scopes and syncing covers what a diagram covers and how to keep it current.

Keeping diagrams true covers what a sync preserves and what the shape outlines mean.

Connecting an AWS account takes four steps: create the connection, create a read-only role in AWS, verify it, then scope a diagram.

You need a Teams licence and cloud_connections.manage on the owning organisation or team. Below Teams the action refuses with "Continuum is a Teams-plan feature."

Regions are fixed when you create the connection: one region in single-account mode, a set of regions in AWS Organization mode. There is no region control on the connection afterwards, so covering a new region means a new connection.

What the role can do

The template grants list and describe actions. Nothing in it changes infrastructure, and Continuum never writes to your cloud account. The external ID stops another Blueprintr tenant assuming your role, so do not omit it. On the current template it is filled in for you.

Reading Terraform state is not included. Adding a state backend to this connection also needs s3:GetObject on the state object added to the role policy.

If a sync will not start

An AWS Organization connection needs the org StackSet role. Pointing one at a single-account role fails to load the account list, because the single-account template grants no organizations: permissions. Create a Single account connection instead, or deploy the StackSet.

A finished sync reports what it could not read, under Adapter errors. Read that list before concluding a resource was decommissioned.

Reaching the connection cap refuses with "Connection cap reached (3 per org)", or "(3 per team)". Blueprintr first reclaims your own drafts that have sat untouched for a day with no credential and nothing referencing them; drafts from the last 24 hours, and anyone else's, are left alone.

Next

Scopes and syncing covers what a diagram covers and how to keep it current.

An Azure connection covers a set of subscriptions through one Entra application granted read-only access.

You need a Teams licence and cloud_connections.manage on the owning organisation or team.

The Federation tile beside Client secret is marked roadmap and cannot be selected yet, so the client-secret path is the only one available.

Secret lifetime

You create the secret in Azure, so Azure decides how long it lives. The copy-and-run script the wizard offers creates it with a two-year life. The portal click-path leaves Azure's own default, so check it before relying on the connection.

Blueprintr encrypts the secret at rest and never returns it to the browser. Replace it later from the connection's detail page rather than by rebuilding the connection.

If verification fails

A connection whose application has no Reader grant fails outright: "The connection authenticated but no subscriptions are visible to it. Assign the Reader role at subscription scope." Grant Reader, then verify again.

Discovery only runs on a connection that has verified, so verify after any credential change.

Terraform state

A Terraform backend can be set on an Azure connection's detail page, but drift reconciliation works on AWS connections only. The form is not provider-gated, so an Azure connection accepts a backend and returns nothing from it.

Next

Scopes and syncing covers choosing subscriptions and locations, and running the first sync.

A scope is what one Continuum diagram covers. On AWS it is one account paired with one region. On Azure it is one subscription paired with one location.

A diagram can carry several, but they must all come from the same provider. Adding an Azure scope to an AWS tab is refused: "This Continuum tab was created from a different cloud provider. Add the scope to its own Continuum tab instead."

Choosing scopes

Pick accounts or subscriptions, then regions. Every combination becomes its own scope, so three accounts and two regions is six scopes. The picker shows the running total.

Two optional narrowings apply on top:

Control	Provider	Default
Refine VPCs / subnets	AWS	Every VPC in the scope
Refine resource groups	Azure	The whole subscription
Tag filter	Both	No filter

A resource is imported when every tag listed matches. The filter applies to all selected scopes.

One commit fans out to at most 12 scopes on AWS and 4 on Azure, and the picker says so when you go over.

On Teams the plan cap of three scopes per diagram bites first, and the picker does not know your plan. A selection of four or more still shows as valid and the server refuses it after you press create. Narrow the selection, or add the rest as extra scopes afterwards.

Adding, re-syncing and removing scopes

Open the Continuum tab's settings cog and choose Settings…. Each scope has Re-sync, and + Add another scope adds more.

Every control here needs edit access on the blueprint plus cloud_connections.manage on each scope's connection. Without the permission the buttons do not appear.

Remove is disabled on the last remaining scope: "Cannot remove the last scope. Delete the Continuum tab instead."

Syncing is manual

Sync now from the cog re-discovers every scope and reports the result, for example "Synced, +3 added, 1 changed, 0 missing."

Reading a sync

Each scope's discovery is recorded as its own Poll run, reachable from the history list in Settings…, so one Sync now across three scopes produces three runs. Removing a scope writes one too.

A run reports what it found, what changed since the last one, and an Adapter errors section listing every read that failed.

Check that section before concluding something was decommissioned. A permission error produces a smaller diagram with an explanation, not a silent gap. Once the permission is fixed, choose Sync now again.

The ten most recent runs are listed. There is no view that compares two runs side by side.

Once a scope has been discovered, Continuum puts the results on a canvas and mints a stratum for every resource it found.

Shapes and strata

Resources the layout draws become shapes, nested inside the boundaries that exist in the source: accounts, regions, VPCs and subnets, resource groups.

Resources that describe relationships rather than occupy space get a stratum with no shape. Route tables, security groups, network ACLs, IAM and KMS are filed under a (Context) folder in the Files sidebar and cross-linked from the resources they affect.

A resource collapsed into a group shape, such as Auto Scaling members or a Lambda name family, also gets a stratum with no shape of its own. Those sit alongside the drawn resources rather than under (Context).

A Continuum stratum's body tab is labelled Continuum rather than Overview. It holds a Resource table, a Details table, per-type tables, Tags, links to related strata, and the full payload in a collapsed Raw data disclosure. A Terraform drift tab joins it where state is reconciled.

What a sync preserves

Containers can grow to make room for additions without moving what is already inside them. Where a container is boxed in by authored content, Continuum places the addition in free canvas space and keeps its resource membership rather than moving your work.

A label or membership you have not customised follows the source. Anything you overrode wins. Managed shapes you deleted stay deleted once the diagram has recorded a refresh baseline. Older diagrams without that baseline preserve customisations conservatively, because a deletion made before the baseline cannot always be inferred.

New resources wait for you

A resource discovered after the first sync is not added to the diagram straight away. It is drawn on the notes layer with a green outline, and the settings cog's menu shows a running delta such as "+3 new".

Choose Promote N new resources from the cog to move them onto the blueprint layer. Until then they sit alongside the diagram rather than in it.

What the outlines mean

Outline	Meaning
Default	Active
Red	The source reports the resource offline
Dashed grey	Pending removal
Red solid, on the notes layer	Removal confirmed
Red dashed, on the notes layer	Referenced from outside the scopes you sync, labelled "out of scope"
Yellow dashed, on the notes layer	In Terraform state but not found in the cloud, labelled "in tf, not in aws"
Green, on the notes layer	Newly discovered, awaiting promotion
Amber	Live configuration has drifted from Terraform state

Drift takes precedence over lifecycle. These outlines come from cloud discovery only. A linked monitoring platform never changes a shape.

Changing the reading direction

Reading direction is not a control on the tab. Ask the AI assistant to reorder the diagram top down or left to right. It proposes the change and applies it only after you confirm.

Version restore is refused

Once a blueprint carries Continuum-managed content, restoring an older version of it is refused. A version snapshot never captured the connections and bindings behind those tabs and strata, so a restore would delete them with nothing to rebuild from. Remove the Continuum component and unbind those strata first.

Binding one shape instead

A shape you drew yourself can be tied to a single live resource. Add a stratum to it, open + Add tab and choose Continuum, then pick a connection, a region or location, and one resource. Pull now re-reads it.

AWS and Azure connections can both be bound. A Terraform-state connection cannot: "Only AWS and Azure connections can back a live stratum."

The control appears only for a signed-in editor on a Teams plan or above, on a rich stratum in a saved blueprint. Binding also needs cloud_connections.manage on the organisation or team that owns the connection; without it the picker reports no usable connections. Readers never see it.

Continuum Link attaches a saved snapshot from an operational platform to a stratum, as its own read-only tab. Alert state, service ownership and change context sit beside the thing on the diagram they refer to.

It needs an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the organisation or team that owns the connection. Below Enterprise the engine refuses with "Continuum integrations are an Enterprise feature." This is a separate gate from the Teams licence Continuum Cloud uses; holding one does not grant the other.

Connect a platform

Open Settings → Continuum on the organisation or team, find Operational integrations, and choose New integration. The form asks for a Type, a Name, whatever non-secret fields that connector declares, and one credential. Choosing Connect & verify stores the credential and runs a handshake against the platform in one step.

Jira Cloud and Jira Service Management Operations replace that button with Connect with Atlassian and sign you in instead. Most other connectors take a pasted token or key, GitHub and GitLab included.

Two groups store no credential here. AWS CloudWatch reuses a verified AWS cloud connection: pick that connection and a region, and widen that connection's role with the CloudWatch and Logs actions the form lists. The seven on-premise connectors keep their credential in the Continuum Local agent's own configuration.

Credentials are encrypted at rest, are never returned to the browser, and are never written into a snapshot. To replace one, enter the new value; there is no way to read the old one back.

Link an object to a stratum

Save the blueprint, open a stratum, and choose Continuum Link from its + Add tab menu. Search across every verified connection you can use, review the candidate's identity, then choose Link object. The first snapshot is fetched before the binding is saved, so a link that would have failed never lands.

One connection holds one linked object per stratum. Selecting a different object from the same connection replaces that connection's binding. A stratum can carry 20 linked tabs; a twenty-first is refused with "This stratum already has the maximum of 20 integration tabs."

Two aids propose candidates instead of you searching. Suggest integrations… on a shape's right-click menu scores matches from that shape's own identifiers. Scan for integrations does the same across a whole blueprint, reading titles, tab bodies, file content and diagram shape labels, up to 200 identifiers per scan. Neither writes anything: Scan attaches only what you tick and apply.

Refreshing is manual

Opening a tab shows its saved snapshot and contacts nothing. Nothing polls, and no schedule exists.

Each linked row has two icon buttons with no visible text. The circular-arrows icon re-fetches, and its tooltip reads "Re-fetch this integration's data". The broken-link icon removes the tab, with the tooltip "Remove this integration tab", and asks you to confirm.

A banner above every saved tab states which of these applies:

Banner	Meaning
Saved snapshot	The last fetch succeeded and is still considered fresh
Snapshot needs a refresh	Older than the connector's freshness window
Incomplete snapshot	Some sections could not be read; counts are lower bounds
Last refresh failed	The previous snapshot is still shown, unchanged
Refresh paused	The connection is suspended

Only nine connectors declare a freshness window: PagerDuty, incident.io, Rootly, Datadog, LogicMonitor, Auvik, Jira Cloud, Jira Service Management Operations and ServiceNow. Most set five minutes. Jira Cloud work items set fifteen, Jira Service Management on-call coverage sets two, and ServiceNow sets one day.

A failed read never becomes a healthy-looking zero. Missing sections are marked unavailable or partial, and a failed refresh keeps the previous snapshot.

Who can read a saved panel

This depends on the connector, so check it before linking.

Connector	Default audience for a new connection
Datadog, LogicMonitor, Auvik, Rootly, ServiceNow	Blueprint editors only
Every other connector	Everyone who can read the stratum

Where a connector has no audience setting, its panel reaches every reader of the blueprint. On a public blueprint that includes anonymous readers, embeds and exports. The five connectors above offer a reader-visible option, labelled All Blueprint readers.

An audience change applies to later fetches. It does not rewrite snapshots already saved, and it cannot recall versions, templates, exports, embeds or AI answers that already carry the data. Unlinking a tab and revoking a credential cannot recall them either.

Managing a connection

Control	What it does
Configure	Edits the connection's non-secret settings, including audience and detail
Verify	Re-runs the handshake, including optional capabilities
Suspend and Resume	Stops and restarts search and refresh. Saved snapshots stay readable
Rotate token or Replace credentials	Reveals a field, then Verify & replace swaps the credential only if the new one verifies
Remove token…	Clears the stored credential and suspends the connection

Deleting a connection is refused while tabs are still bound to it: "This integration has N stratum tab(s) bound to it. Remove those first."

If the plan lapses, the section stays open in a cleanup-only mode. You can suspend, inspect, unlink and disconnect. Adding or refreshing data needs Enterprise again.

Which platforms

38 connectors are registered. 28 work directly, 7 more need Continuum Local for systems Blueprintr cannot reach, and 3 are declared but not built, shown as "On the roadmap".

The connector reference lists all of them with what each one asks for and shows. Eight have a guide of their own:

38 connectors are registered. 28 connect directly, 7 need Continuum Local, and 3 are declared but not built. All of them need an Enterprise licence and continuum_integrations.manage, and none of them draws on a canvas.

Every connector can be found by free-text search when linking a stratum. Where a credential field has no label of its own, the form calls it API token.

Alerting and on-call

Connector	Credential	Other fields	Panel
PagerDuty	API token	PagerDuty region, Imported content	Service identity, open incidents, incident coverage, ownership, on-call coverage, related services
incident.io	API key	Catalog types, relationship fields, attributes, history days, remediation counts	Catalog entry and related incidents, or one incident with durations and follow-ups
Rootly	API key	Content audience, ownership context, on-call coverage, action item counts	Service response and history, or one incident's lifecycle
Jira Service Management Operations	Atlassian sign-in	Site, counts-only	Alert scope with open, unacknowledged and snoozed counts, or an on-call schedule
FireHydrant	API key	None	Service tier and active incidents, or one incident
Splunk On-Call	API credentials (JSON)	None	One incident, paged teams and state transitions
xMatters	Password	Instance URL, Username	A group, a person or an event, with recent events

Observability

Connector	Credential	Other fields	Panel
Datadog	Datadog credentials	Datadog site, content audience, saved detail, approved tag keys, Software Catalog, SLOs, default SLO window	Host, monitor, catalog service or reliability objective
New Relic	User API key	Region (optional)	Entity identity, alert severity, reporting state and tags
Dynatrace	API token	Environment URL	Entity identity and open problems by category, with a timeline
Elastic Observability	API key	Kibana URL	Alert rule identity, active count and execution status
Splunk Observability Cloud	Access token	Realm	Detector state, active incidents by severity, current signals
Grafana Alerting	Service account token	Grafana URL	Firing alerts for a label matcher, or one alert rule's state

Monitoring

Connector	Credential	Other fields	Panel
LogicMonitor	Bearer token	Company, content audience, saved detail, group scope, maintenance context, instance datapoints	Device, DataSource instance or resource group
Auvik	API key	Region, Username, site scope, audience, saved detail, alert history period, optional sections	Device context and recent alert history
AWS CloudWatch	None	A verified AWS cloud connection and a region	An alarm with recent state changes, or a log group with event volume
Azure Monitor	Client secret	Tenant ID, Client ID, Subscription ID	Resource identity, alerts by severity, recent alerts
Google Cloud Monitoring	Service account key (JSON)	Project ID	Alert policy and its conditions
Prometheus Alertmanager	Password	Alertmanager URL, Username (optional)	Alert counts for a matcher, top labels, firing since

CloudWatch is the one cloud connector that stores no credential of its own. It reuses a verified cloud connection, so the form offers a connection and region picker instead of a token field.

That connection's role needs nine CloudWatch and Logs actions the discovery role does not grant. The form lists them under Required IAM actions for the backing role; add them before expecting alarm or log-group data. On an organisation-mode connection the form also asks for a 12-digit member account id.

Alertmanager always requires a secret to save the connection. For an unauthenticated instance, leave Username blank and type any placeholder in Password. It is never sent without a username.

Google Cloud Monitoring shows alert-policy configuration only. Its panel states "Open incidents unavailable".

Uptime and synthetics

Connector	Credential	Other fields	Panel
Pingdom	API token	None	Check identity, uptime percentage, average response, state changes
Better Stack Uptime	API token	None	Monitor identity, SLA and incident counts, active incidents
UptimeRobot	API key	None	Monitor identity, recent health and window totals
Checkly	API key	Account ID	Check identity, sampled results, latest runs
Site24x7	OAuth credentials (JSON)	OAuth client ID, Data centre (optional)	Monitor state, account-wide fleet status, current problem monitors

Service management and source control

Connector	Credential	Other fields	Panel
Jira Cloud work items	Atlassian sign-in	Site, counts-only	One work item, a saved filter or a JQL scope
ServiceNow CMDB	Password	Instance URL, Username, Snapshot audience, Saved detail, Open work	Configuration item with lifecycle, environment, ownership groups and discovery dates; relationships from the CI's side with the total; optional open incident and change counts
GitHub	Access token	Organization (optional)	Repository identity, activity, recent issues and workflow runs
GitLab	Access token	Instance URL (optional)	Project identity, activity, recent issues and pipelines

On-premise, through the local agent

These seven appear in the connector list but cannot be selected until the organisation has an enrolled agent that is online. Until then the option is disabled and reads "Needs a Continuum Local agent". Their credentials live in the agent's own configuration and are never sent to Blueprintr, so the connection form has no credential field.

Connector	Credential parts in the agent config	Other fields	Panel
SolarWinds Orion	username and password	Orion server URL, Orion username	Node identity, health metrics, active alerts, interfaces, volumes
Zabbix	token	Zabbix frontend URL	Host identity, unresolved problems, current problems
PRTG Network Monitor	token	PRTG server URL	Device identity, sensor counts, unhealthy sensors
Checkmk	username and password	Checkmk URL, Site, Automation user	Host identity, service states, current problems
Icinga 2	username and password	API URL, API user	Host identity, service states, active problems
ManageEngine OpManager	token	OpManager URL	Device identity, active alarms
WhatsUp Gold	username and password	WhatsUp Gold URL	Device identity and active monitor counts

For SolarWinds Orion, Checkmk and Icinga 2 the username typed into the connection form is replaced by the agent's own at dispatch, so set it in the agent config.

Declared but not built

NetBox, Infoblox and Veeam Backup & Replication appear in the connector list as disabled options marked "On the roadmap". They cannot be connected.

Reading any panel

Whatever the connector, the same rules hold.

• Data is fetched with the connection's credential, not the reader's. A source link opens the provider, which applies its own permissions.
• A panel is a named projection of the provider's response. The raw upstream object is never stored as-is.
• A failed read never becomes a zero. Sections are marked unavailable or partial, and partial counts are lower bounds.
• A provider that cannot be reached leaves the saved snapshot in place. The tab keeps its last successful body and the banner reads "Last refresh failed". A first link that cannot fetch is refused, so no tab is created.
• A saved panel reaches everyone who can read the blueprint unless its connector has an audience setting. Only Datadog, LogicMonitor, Auvik, Rootly and ServiceNow have one. On a public blueprint every other panel is visible to anonymous readers, embeds and exports.
• Counts describe what was retrieved at the stated time. They are not a statement that the component is healthy now.

Link a PagerDuty technical service to the stratum for the component it covers. The saved tab shows who owns the service, what is open against it, and whether the primary escalation level had cover when it was fetched. Responding to incidents stays in PagerDuty.

A PagerDuty technical service is the only object that can be linked. Business services appear inside a service's panel as related rows, and cannot be linked on their own.

Connect

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In PagerDuty, create a dedicated read-only REST API key under Integrations → Developer Tools → API Access Keys. An Events API integration key will not work here. If you paste one, Blueprintr sends it and PagerDuty rejects it with "PagerDuty services read failed (HTTP 401). Check or replace the REST API key."
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, and select PagerDuty as the Type.
4. Give the connection a Name, set the two options below, paste the key into API token, and choose Connect & verify. Without a name the form refuses with "Give this integration a name."

Connection options

Both dropdowns open on Use default, which stores nothing and behaves as the first real option.

Field	Options	Effect
PagerDuty region	Use default, United States (US), Europe (EU)	Chooses the API host. Use EU for accounts whose address ends in eu.pagerduty.com. Default is US
Imported content	Use default, Summary (recommended), Detailed: include titles and description	Detailed adds incident titles and the service description. Default is Summary

Verification makes two list calls, one for services and one for incidents. Both may return nothing and still verify, so a successful check proves the key reads those collections, not that the account has content. On-call coverage and service dependencies are not exercised at verification time, so they may still fail when a service is linked.

Link a service

Open the stratum and choose Continuum Link, then search by any of these. PagerDuty has no prefix syntax.

What you type	What happens
A service name	Searches service names, up to about 300 services
A service ID (6 to 32 uppercase letters and digits)	Looked up directly. If PagerDuty returns 404, the same text is searched as a name
A PagerDuty service URL	The ID is read out of /service-directory/<ID> or /services/<ID>. The URL itself is never called

A URL from the other region is refused rather than looked up: "This PagerDuty service URL belongs to a different region. Choose the matching connection."

What the panel shows

Section	Contents
Service	Service, Service ID, Region, Incident posture, Meaning, Owning team, Escalation policy, and the description in Detailed mode
Open incidents	Counts of reported open, high-urgency, low-urgency, unknown urgency and unknown status
Incident coverage	Retrieval, time range, content mode, how many incidents are shown, and a consistency row when the two reads disagree
Open incident details	Up to 20 incidents, newest first
Ownership in PagerDuty	Links to the escalation policy and the owning team
On-call coverage	Whether the primary level had cover, when to recheck, and a privacy note
Service relationships	Retrieval state, then a table of related services

The headline restates PagerDuty's service status: "No open incidents reported", "Acknowledged incidents", "Triggered incidents", "Maintenance · new incidents suppressed" or "Disabled · new incidents suppressed". The Meaning row spells out the limit of that reading: "PagerDuty incident and notification state; not a measurement of component availability."

If the service read and the incident read disagree, the headline is replaced with "Service and incident state disagree · refresh to recheck" rather than showing a healthy state.

Counting and its limits

Open incidents are those PagerDuty reports as triggered or acknowledged, with no creation-date cutoff. Retrieval stops after five pages of up to 100, so roughly 500 incidents. When that cap is reached, the section title gains "partial retrieval", every count gains a trailing plus sign, and the Retrieval row reads "Partial: stopped after 5 pages; counts are lower bounds."

On-call coverage is computed over one hour starting at the fetch, filtered to the service's escalation policy. If those pages could not all be read, coverage reads Unknown rather than claiming a gap: "Coverage retrieval is partial; absence does not establish a coverage gap." A service with no escalation policy makes no on-call call at all.

Related services are limited to six detail lookups. Business services never carry a state, showing "Business impact not retrieved", because the connector does not infer business impact.

What is never imported

Responder names, user IDs, email addresses and schedule names are excluded in both content modes. So are incident bodies, assignees, acknowledgers, conference-bridge numbers, service integration keys and business-service points of contact. Detailed mode adds exactly two fields: the incident title, truncated to 250 characters, and the service description, truncated to 1000 characters.

Only pagerduty.com HTTPS links reach the panel, with query strings and fragments stripped.

Audience

PagerDuty declares no audience setting, so its saved panel is visible to everyone who can read the stratum. On a public blueprint that includes anonymous readers, embeds and exports. Service names, team names and relationships are visible even in Summary mode.

Choose Detailed only when incident titles and the service description are appropriate for that audience. Reducing detail later applies to subsequent refreshes and does not recall copies already shared.

Changing the region later

Changing the region is refused while any binding predates the region setting: "Remove the existing legacy bindings before changing PagerDuty region, then link services from the new region."

If every binding does carry a region, the change is allowed, and each of those services then fails on refresh with "This service was linked in a different PagerDuty region. Unlink it and choose the service again." The new region is verified with the existing credential before it saves, so a US-only key fails the switch to EU and the previous setting is kept.

Refreshing and recovery

Snapshots become due for refresh after five minutes, which is a reminder rather than automatic polling. A failed service or incident read keeps the previous snapshot and adds a warning; it never becomes a healthy zero. A failed on-call or dependency read marks only that section unavailable and still saves the panel.

Link an incident.io Catalog entry to the stratum for a service or component, and the tab shows the incidents that named it. Link an incident instead, and the tab explains one response: its lifecycle, severity, measured durations and follow-up state. Responding and writing up stay in incident.io.

Connect

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In incident.io, create a dedicated key under Settings → API keys with View data (viewer) and View catalog (catalog_viewer). Leave write permissions and View all incident data (global_access) disabled.
3. In Blueprintr, open Settings → Continuum, go to Operational integrations, choose New integration, and select incident.io as the Type.
4. Give the connection a Name, paste the key into API key, set any of the optional fields below, and choose Connect & verify.

Verification reads the key's identity, one incident, the Catalog type list, one Catalog entry, the custom-field list when relationship fields are configured, and one follow-up when remediation counts are on. All requests are reads against api.incident.io.

Optional connection settings

Every field can be left blank. The three list fields accept up to 50 comma-separated IDs each. Ask your incident.io administrator for the stable IDs.

Field	Blank behaviour	What it changes
Catalog types to search	Searches available types within the retrieval budget	Restricts search to the service or component types your diagrams use
Incident relationship fields	An incident counts if it selects the entry in any custom field	Counts an incident only when it selects the entry in the listed fields, such as Affected services
Catalog details to share	No attributes are shown at all	Adds selected structured attributes, such as owning team or tier, visible to every blueprint reader
Recent incident history (days)	30	The window for the "created in the last N days" count. Accepts 1 to 90
Include remediation counts	Off	Adds aggregate follow-up state. Needs the actions.view permission and the matching incident.io entitlement

Active, triage and paused incidents are checked regardless of age, so the history window only bounds the recent-history count.

Link an object

Open the stratum, choose Continuum Link, and search. Once an incident.io connection is in play, an incident.io objects selector appears with Catalog and incidents, Catalog records and Incidents. Search a name, a stable ID, an INC number or an incident link.

What you type	What it finds
A name	Catalog entries, incidents, or both, depending on the selector
INC-1042 or a bare number	That incident directly, including one older than the history window
A 26-character ULID or a UUID	That record directly
An app.incident.io incident link	That incident directly

Typing catalog: or incident: in front of a query narrows it the same way the selector does.

What is always excluded

Blueprintr applies its own filter before anything reaches a panel, whatever the key is permitted to read.

• An incident appears only when incident.io marks it organisation-visible and its mode is standard or retrospective. Private, test, tutorial and stream incidents never appear. Linking one returns "incident.io incident is private, unavailable, or a test record and cannot be linked."
• A Catalog type that represents people or customers is dropped, whether by its category or by user, person, customer, contact or employee appearing as a word in its name. Linking an entry of that type fails, but the reason is not shown: the editor sees the generic "incident.io could not be reached", so check the type's category and name before suspecting the connection.
• Only three shapes of Catalog attribute can be shared: numeric, boolean, and a relationship to a team, service or product-feature type. Free text is excluded. An attribute whose name suggests a secret, a token, an email address or a phone number is excluded even when its type is numeric, and selecting it fails verification.

Approved attribute values are clamped further: at most 10 records per attribute, numbers must parse as numbers, and a relationship label must be 160 characters or fewer with no line break and nothing shaped like an email address.

What a Catalog panel shows

Section	Contents
Catalog entry	Name, Type, ID, External ID, Catalog state, Updated
Related incidents	Active, Triage, Paused, created in the last N days, Coverage, Relationship
Approved Catalog relationships and metadata	The attributes you selected, or nothing when none are configured
Related incident details	Up to 10 incidents, open first and then newest first

The Coverage row states the limit of the reading: "Organization-visible standard and retrospective incidents only; private records are excluded. A related incident does not by itself establish component health."

The headline is one of: "Archived Catalog entry", "Related incident coverage incomplete", a count of related active incidents, a triage and paused count, or "No related active incidents in available scope".

What an incident panel shows

Reference, lifecycle, status, severity, whether a lead is assigned, and created and updated times. The lead row reads Assigned, Unassigned or Unknown, and never names the person. Below that sit measured durations with their availability, the incident's timestamps, and links out to the incident, the postmortem and any linked issue.

With remediation counts on, a Follow-ups section adds outstanding, completed, not-doing and unknown-status totals. Descriptions and assignees are not imported.

Partial results

Retrieval is bounded. When a page limit or budget is reached, counts are prefixed "At least", the panel adds a coverage-incomplete section, and the snapshot is marked partial. A count from a partial read is a lower bound, never a total.

Common messages an editor sees:

• "incident.io needs Catalog read access. Ask the connection owner to enable catalog_viewer and Verify in Settings → Integrations."
• "incident.io needs actions.view access for remediation counts. Enable that read permission or turn off remediation counts, then Verify."
• "incident.io results are incomplete. Narrow the Catalog types or search scope, then retry; open incident.io for the full view."
• "incident.io request limit reached. Wait a minute, then retry."

Audience and refreshing

incident.io declares no audience setting, so its saved panel reaches everyone who can read the stratum, including anonymous readers of a public blueprint. Incident references, names, severities and any approved Catalog attributes are visible to them. In incident.io, organisation-visible does not mean suitable for the public, so review a record before linking it.

Snapshots become due for refresh after five minutes, as a reminder rather than automatic polling. A failed refresh keeps the previous snapshot with a warning. Changing a setting applies to later fetches and does not rewrite copies already saved or shared.

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.

Connect a Rootly service to the stratum for a system component, or link an incident to the stratum explaining a failure or recovery process. Readers can understand the response in the diagram's context and open Rootly for the full incident record. Blueprintr reads information; incident management stays in Rootly.

Connect and choose an object

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In Rootly, open Organization Settings → API Keys → Generate New API Key. Prefer a dedicated Global API key assigned read-only Incident Response and, only if needed, On-Call roles. Personal keys inherit their creator's access; Team keys inherit Team Admin permissions. See Rootly's API-key guide.
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, and choose New integration. Select Rootly as the Type, give the connection a Name, enter the API key, review the audience and optional settings, then choose Connect & verify. Verification checks service and incident reads. There is no separate enable step.
4. Save the blueprint, open the relevant stratum, and choose Continuum Link from its + Add tab menu. Search for the service or incident and review its identity before linking. Suggest integrations… on a shape and Scan for integrations across the blueprint both propose Rootly matches, and attach nothing until you apply them.

Blueprintr uses Rootly's hosted API at api.rootly.com. This connection does not provide an alternative regional or self-hosted endpoint.

Choose the information and audience

Setting	Default	What it changes
Rootly content audience	Blueprint editors	Keeps saved Rootly details visible to blueprint editors. Choose the reader-visible option, All Blueprint readers, only after approving the information for everyone who can read the blueprint. Its full label adds "approved metadata".
Service ownership and context	On	For linked services, adds related services, teams, environments, repository names and deployment names. Turn it off to omit optional context reads.
On-call coverage	Off	For linked services, adds on-call coverage when the key and Rootly account support it. Individual responders and their contact details are omitted.
Incident action item counts	On	For linked incidents, adds aggregate task and follow-up progress from incident action items. Task descriptions and assignees are omitted.

The baseline key needs read access to services and incidents. Context may also require team and environment reads; follow-up summaries need incident action-item reads. On-call coverage needs access to Rootly's on-call data and the relevant product entitlement. These are permissions on the key's assigned roles, not OAuth scope strings. Disable an optional capability instead of granting unrelated administrative access.

Rootly incidents marked private, or without a reliable privacy designation, are excluded from selection and saved incident data under either audience setting. Rootly's non-private designation does not itself make an incident appropriate for the public. Review titles, service names and relationships before switching to the reader-visible audience.

Read the snapshot

A service panel separates active response from recent history and maintenance. Normal incidents and sub-incidents are distinguished by kind; test incidents do not count as production incidents. The active view is independent of the 30-day history window, so an older unresolved incident can still be relevant. Maintenance has its own state and planned window when available; it does not become an outage merely because it is in progress. Rootly documents these filters in its incident API.

An incident panel shows response state, severity, related services and lifecycle times when available. Mitigated means impact has been reduced or halted; it does not mean response work is complete. Follow-up progress helps distinguish incident resolution from outstanding improvement work. Open Rootly to read descriptions, communicate with responders or change the record.

Opening a tab displays saved data. Re-fetch with the circular-arrows icon on the linked row, whose tooltip reads "Re-fetch this integration's data". Rootly snapshots indicate that another refresh is needed after five minutes; this is a freshness warning, not automatic polling. On-call coverage is limited to the time checked. Incident counts describe retrieved records, not a guarantee that the system is healthy.

Missing information and recovery

An unavailable incident list, incomplete pagination or unreadable optional section is shown as unavailable or partial, rather than as zero incidents or no outstanding work. If a whole refresh fails, the prior snapshot remains with a warning. Check the key's role and expiry; for rate limits, wait for the stated retry interval before refreshing again.

Rotate a credential with Rotate token, then Verify & replace, which swaps it only if the new key verifies. Suspend stops search and refresh while leaving saved snapshots readable, and Resume restarts it. The broken-link icon on the linked row removes the binding. The connection can be deleted after its bindings have been removed.

Copies and rollout checks

New snapshots restricted to editors use Blueprintr's existing audience controls for readers, embeds, viewer exports and search or AI indexing. Editor exports and backups retain the source. Approved reader-visible snapshots follow the blueprint's audience, including anonymous readers of a public blueprint.

Settings apply to subsequent fetches. Restricting the audience does not rewrite panels already saved: refresh each linked tab successfully, or unlink it, before treating existing Rootly content as editor-only. Changing the audience also does not rename existing strata or link labels, or remove authored notes outside the managed panel. Templates, version history, exports and other existing copies are not retroactively rewritten or recalled by an audience change, key revocation or unlink.

Before operational rollout, verify the connection against your Rootly account: service membership, a known older active incident, maintenance, private-incident exclusion, optional permissions and on-call coverage. Local fixture tests do not establish your account's entitlements or replace this live check.

Connect Datadog to the stratum for a component on your diagram. Use a host to explain telemetry reporting, a monitor to explain an evaluated condition, a catalog service to explain ownership and dependencies, or an SLO to show performance against an objective. Open the linked Datadog record for detailed investigation and operational changes.

Connect

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. Create a dedicated Datadog service account with read permissions. Follow Datadog's key setup or Service Access Token guide.
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, select Datadog as the Type, enter a Name, and choose the Datadog site. If you use a custom Datadog domain, find the underlying site in My Preferences. See Datadog sites.
4. Under Datadog credentials, set Credential type to API key and application key, or to Service Access Token and fill that field. A Service Access Token pasted into the application-key box is rejected.
5. Review the information and audience settings, then choose Connect & verify. Blueprintr stores credentials encrypted and never displays them after saving.

Hosts and monitors require hosts_read and monitors_read. Enable optional capabilities only when needed:

Capability	Additional permission	Information saved
Service Definitions, schema v2.2 and earlier	apm_service_catalog_read	Service ownership and structured operating links
Software Catalog, schema v3	apm_service_catalog_read	Supported catalog entities, owners and declared or discovered relationships
Reliability objectives	slos_read	Selected SLO target, performance, observation window and error budget

Catalog versions use distinct APIs. Choose the one your account uses and verify availability on your site. Datadog sites are independent and product availability differs. The connection reads existing information; it does not create monitors, SLOs, public dashboards or new telemetry instrumentation. Your existing Datadog entitlements and API limits still apply.

Choose the component's operational context

Save the blueprint, open its stratum, and choose Continuum Link from the + Add tab menu. Search by host or monitor name, paste a Datadog monitor, SLO or infrastructure source link, or use one of these forms:

Search	Use
monitor:12345	Select an exact monitor
service:checkout env:production	Find the catalog service for this deployment
slo:0123456789abcdef0123456789abcdef	Select an exact SLO
slo-id:objective-id	Explicitly select an SLO by its exact ID, including other supported ID formats
slo:Checkout availability	Find a named objective

Review the connection, stable identity and source preview before linking. Catalog and SLO searches require the corresponding connection option.

Linking a Datadog service requires its exact env tag value, without spaces or wildcards. For other Catalog entity kinds the field reads Environment (optional) and may be left blank. The service identity and deployment environment serve different purposes; changing a deployment's version tag does not make it a new service. Unified service tagging explains Datadog's service, env and version relationships.

Add an explicitly selected SLO ID to a service and choose its window. Check that the objective describes this service and environment: a similar name is not proof of that relationship. Standalone SLO selection also lets you choose 7, 30 or 90 days, where supported by the objective.

For a multi-alert monitor, optionally copy the exact Datadog group string to show that group's state. Without a group, the panel describes the monitor's aggregate state. One monitor may cover many hosts or environments; its aggregate alert is not proof that every component is affected.

Suggest integrations… and Scan for integrations offer matches for review. Use manual search when you want to choose an environment, SLO or monitor group. Each connection has one managed tab per stratum; choosing a different object explicitly replaces its binding. Authored prose and diagram content stay intact.

Read the saved information

Host reporting means whether Datadog received the expected metrics. Missing telemetry is not proof that a host is down. Hosts outside Datadog's available inventory window can become unavailable. Monitor panels retain distinct alert, warning, no-data and other provider states; these are evaluated conditions, not a general guarantee of system health.

Catalog v3 separates declared relationships from those Datadog discovers through APM or Universal Service Monitoring. If provenance cannot be established, it is labelled unknown. These relationships are catalog-wide; the selected monitor environment does not filter this topology. The earlier Service Definitions API supplies ownership and links, with no relationship retrieval. Catalog navigation opens your regional Software Catalog; use the displayed entity identity to locate the component. Structured operating links may include documentation, runbooks and dashboards recorded on the selected entity. Blueprintr does not discover every dashboard or publish dashboard contents.

SLO panels show the objective's target and calculated performance for the selected window. Error budgets retain their units and may be negative when the budget is exhausted. Blueprintr never substitutes 100% for an unavailable calculation. Datadog's own no-data rules still apply: monitor SLOs follow the underlying monitors' settings, and time-slice SLOs count no-data periods as uptime. The panel explains these limits. See Datadog's SLO history and monitor details.

Opening a tab displays its saved snapshot. Re-fetch with the circular-arrows icon on the linked row ("Re-fetch this integration's data"). Snapshots show their retrieval time and become due for refresh after five minutes; this is a freshness warning, not automatic polling. Incomplete retrieval is labelled partial. Counts from a partial list are lower bounds; an unavailable section does not mean zero. A failed refresh keeps the previous snapshot with a warning.

Information and audience

New connections default to Blueprint editors and Summary. Summary retains the identity and operational measures while keeping monitor detail to a minimum. Detailed mode can include monitor names and approved tag values; new connections approve only service, env and version tag keys initially. Enter none to omit tags; clearing a configured list also omits tags on the next refresh. Monitor messages, notification recipients and raw telemetry are omitted.

Choose the reader-visible option, All Blueprint readers, whose full label adds "approved metadata", only after reviewing the information for that audience. A public blueprint can have anonymous readers who do not authenticate to Datadog. Host identities, service names, ownership, links and even selected tag values may be confidential.

Settings affect subsequent successful refreshes; they do not rewrite existing snapshots. Editor-only panels follow the shared reader, embed, viewer-export and search or AI audience controls. Editor exports and backups can retain the source data. Names in authored notes or link labels outside the managed panel need separate review.

Unlinking, reducing detail, revoking credentials or changing audience does not recall saved versions, templates, exports, AI answers or copies already shared.

Recovery and disconnection

Verification checks the required reads and enabled optional capabilities. Host and monitor reads must pass. If an enabled Catalog or SLO check fails, the connection stays usable for hosts and monitors and the verification notice shows which optional access needs attention. After reloading settings, use Verify to recheck optional availability; the stored verified status alone does not establish it.

If access is denied, check the site's selection, credential expiry and exact read permissions. Scoped keys do not inherit extra permissions. Newly created keys can take a few seconds to propagate. For rate limits, wait for the stated retry interval before refreshing; see Datadog's rate-limit guidance.

Use Rotate token, then Verify & replace, for credentials. Replacing an application key while keeping the same API key preserves links. Changing the API key or Service Access Token requires reviewing and linking objects again, because Blueprintr cannot assume the new credential addresses the same account. Changing sites also requires relinking. Older bindings must be unlinked before these changes. A failed credential verification preserves the previous credential.

Suspend stops search and refresh while retaining snapshots, and Resume restarts it. The broken-link icon on the linked row removes the binding and its managed tab. Remove all bindings before deleting a connection. Remove its stored credential and revoke it in Datadog when access should end.

Before operational rollout, validate your site's permissions, known host and monitor groups, missing telemetry, large result sets, SLO calculations, optional Catalog availability and regional source links against your own account. Local fixtures do not establish live product availability or account entitlements.

Link a LogicMonitor device, DataSource instance or resource group to the stratum for the component it describes. A server can show the conditions affecting it; a circuit can show the exact monitored interface; a site can show the observed state of its group members. Investigation, alert acknowledgement and configuration changes remain in LogicMonitor.

Connect your portal

1. You need an Enterprise licence, blueprint edit access and continuum_integrations.manage on the connection's organisation or team.
2. In LogicMonitor, create a dedicated API-only user. Assign a role with Resources View on only the resource groups Blueprintr should read. Device, group, alert, instance, metric and scheduled downtime reads use resource permissions. Write, alert acknowledgement and Collector settings permissions are unnecessary. See Resources role permissions.
3. Create a Bearer API token for that user. This connector accepts Bearer tokens. LogicMonitor also supports LMv1 authentication, but an LMv1 access ID and key pair cannot be pasted into this connector's Bearer field.
4. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, select LogicMonitor as the Type, and enter a Name, Company and Bearer token. For https://acme.logicmonitor.com, enter acme as the company.
5. Review the content audience, saved detail and optional settings below, then choose Connect & verify. Verification checks resource and alert reads with the supplied credential. A successful check with no visible devices is explained separately: review the user's resource-group access or add monitored resources. Verification does not establish complete coverage or verify every optional read. Save the blueprint before adding a link.

This connection uses REST v3 on commercial logicmonitor.com portals. The portal host is always built as <company>.logicmonitor.com, so LMforGov portals and custom API hosts cannot be reached. No local agent is required. Credentials are encrypted and are not displayed again after saving. LogicMonitor documents the supported authentication methods in its REST authentication guide.

Choose the object your diagram describes

Open the stratum for your server, interface or site and choose Continuum Link from its + Add tab menu. Only a rich stratum can host a linked tab. Search its name, hostname or IP, or paste a current UIv4 device or group resource URL from the portal.

Review the connection, company, object type, stable ID and instance lineage before choosing Link object, especially when names repeat. A successful first fetch is required before the binding is saved. One connection can have one linked object on a stratum; selecting another explicitly replaces that connection's previous link.

What the stratum describes	How to select it	What to check
A server or network device	Search a name, hostname or IP, or use device:42 for an exact device ID.	Confirm the company and device identity; the same display name can exist more than once.
An interface or monitored component	Find its device, choose Browse instances, then select the instance. instances:42 also lists instances on device 42.	Confirm the device, device-specific DataSource and instance. A DataSource's global ID is different from its device-specific DataSource ID.
An exact known instance	Use instance:42:123:456: device ID 42, device DataSource ID 123, instance ID 456.	Retain all three IDs; an instance name or portal instance URL alone does not establish its complete identity.
A site or service group	Search a group name or use group:London or group:7.	Confirm the group path and displayed direct or descendant scope. Membership describes an administrative monitoring group, not an architectural dependency.
A device within a group	Choose Browse members or use members:7.	This lists direct members. Browsing changes the search; it does not save a link.

Suggest integrations… and Scan for integrations can help match diagram identifiers. Every suggestion still needs your review. Search results are limited to what the dedicated LogicMonitor user can read; no match does not prove that the object does not exist. Resolve any reported search or coverage warning before relying on absence.

Choose detail, scope and audience

These settings belong to the connection. Detail, audience, maintenance and datapoint changes apply to subsequent fetches. The group scope is saved with the selected object: review and relink a group to change its scope.

Setting	New connection default	What it changes
LogicMonitor content audience	Blueprint editors	Restricts the saved provider panel to blueprint editors. Choose the reader-visible option, All Blueprint readers, whose full label adds "approved metadata", only after approving the content for everyone who can read the blueprint.
Saved detail	Summary	Keeps object identity, operational states, counts and coverage with less monitoring detail. Detailed adds the affected monitoring names and member context.
Resource group scope	Direct members	Include descendant groups also includes resources within child groups when selecting a group. Duplicate memberships do not represent separate resources.
Maintenance context	Include maintenance windows	Adds available scheduled downtime context. Disable it to skip optional maintenance window reads. Alert downtime flags can still appear in Detailed snapshots.
Instance datapoints	Blank	Optionally enter up to three exact comma-separated datapoint names copied from the chosen DataSource instance. Metrics are fetched only for instance links and only when this field is populated.

Existing connections keep their historical reader-visible detailed behaviour until an administrator chooses otherwise. Existing settings with no maintenance option do not enable additional maintenance reads.

Alert messages, acknowledgement comments, arbitrary resource properties and Collector configuration are not imported. Summary information still includes resource identity and operational metadata: it is not anonymous. Datapoint names and availability vary by DataSource; choose names meaningful to the interface or component rather than assuming every instance provides the same metrics. The instance API and data API describe this resource hierarchy.

Read the saved observation

The panel distinguishes active alert severity, collection availability and maintenance. Detailed snapshots also show acknowledgement and the affected DataSource, instance and datapoint. Acknowledgement means someone has acknowledged an alert; it does not mean the condition has recovered. Scheduled downtime can suppress notifications while monitoring continues. A Collector problem means the resource's current observations may be unavailable. None of these states should be read as a general guarantee of system health. See LogicMonitor's scheduled downtime rules.

Alerting flags describe the object's local setting. The panel does not resolve every inherited group or DataSource alert-suppression rule; check the provider when deciding whether notifications should be sent.

Maintenance windows on an instance panel describe its parent device and can include other monitoring scopes; they are not all specific to the selected instance. A group panel reads schedules for the selected group, without individually retrieving schedules for every member device or child instance. Use each alert's downtime flag and the portal for precise maintenance scope.

Counts describe the active alerts and resources retrieved within the connection's permissions and selected scope. If pagination cannot be completed, the panel marks its coverage as partial; do not treat a lower bound as the full total. Unknown, missing or unreadable information is not zero. Last NetFlow receipt, if displayed, describes NetFlow specifically and does not establish the freshness of all monitored data.

Optional instance metrics request the past hour and show the latest 12 samples per selected datapoint, together with the requested and returned windows, sample interval and missing-data information. Summary mode uses generic metric labels; Detailed mode includes the selected datapoint names.

Opening the stratum displays a saved snapshot and does not call LogicMonitor. Re-fetch with the circular-arrows icon on the linked row ("Re-fetch this integration's data"). After five minutes, the snapshot indicates that another refresh is needed. This is a freshness reminder, not automatic polling. Each metric has its own sample time; fetching a panel now does not make an older provider sample current.

Use the source link to continue investigating the selected device, group or instance in LogicMonitor. A link does not grant access: the provider still applies the signed-in user's own permissions. Extended graphs, alert messages, acknowledgement and configuration remain in the portal.

Recover from failures and disconnect

A failed required read does not become an empty, healthy observation. A failed refresh keeps the previous snapshot and shows a warning. An optional section that cannot be retrieved is marked unavailable or partial. Check resource permissions and token expiry, then verify the connection again. For rate limits, wait before retrying; repeated browsing and refreshes consume the portal's API capacity.

Use Rotate token, then Verify & replace, to rotate a token. The replacement is verified before it replaces the working credential. Suspend stops search and refresh while saved snapshots stay readable; Resume restarts it. The broken-link icon on the linked row removes the current binding; delete the connection after its bindings have been removed. Moving to a different portal requires reviewing and relinking object identities; device IDs are not portable between companies.

Sharing and retained copies

Provider data is fetched with the connection's credential. Readers are governed by the configured Blueprintr audience, not their individual LogicMonitor permissions. Approved reader-visible content can reach anonymous readers of a public blueprint, embeds, exports and configured search or AI features. Editor-only panels use Blueprintr's existing audience controls for those reader surfaces; editor exports and backups retain the source.

Changing a setting affects later successful fetches. Restricting the audience does not rewrite panels already saved: refresh each linked tab successfully, or unlink it, before treating existing LogicMonitor content as editor-only. It does not redact independent versions, templates, exports or copies already shared. Unlinking, suspending or revoking a token cannot recall those copies. Authored stratum names, link labels and notes remain your content and need a separate audience review.

Validate before operational rollout

Automated tests exercise simulated provider responses; they do not establish that a particular LogicMonitor tenant grants the expected access. Before relying on this integration operationally, verify a least-privilege token, duplicate names, an exact instance, direct and descendant group membership, multi-page results, special-character searches and a permission-denied read in a representative portal. Confirm metric units and gaps, scheduled downtime, source links, freshness reminders and the published-reader audience. Check rate limits and any feature entitlements with that tenant. The integration does not import LogicMonitor topology or create monitoring configuration.

Link an Auvik Network Management device to the stratum for a switch, firewall, server or other component in your diagram. The saved panel helps readers identify the device, understand its network context and review recent alert events. Open Auvik for its current dashboards, detailed investigation and operational actions. Continuum Link does not redraw the diagram.

This connection uses Auvik Network Management. It does not import Auvik SaaS Management applications, users, licences or security logs.

Connect and select sites

1. You need an Enterprise licence, edit access to the blueprint and continuum_integrations.manage on the connection's organisation or team.
2. Create a dedicated Auvik service account with a custom API-only role and access to the intended sites. Give it read access to API – Device info, API – Alerts and API – Tenants. Auvik's built-in Read Only role does not grant these API permissions, and its built-in API Access Only role grants unrelated reads and tenant editing. Build a custom role with only the reads listed above. See Auvik's service-account guidance.
3. In Auvik, open My Profile → Manage API Credentials and generate the key. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, and select Auvik as the Type. Give the connection a Name, then enter Region, Username and the API key.
4. Review Auvik snapshot audience, Saved detail and the optional sections, then choose Connect & verify. To restrict the connection to named sites, select Configure on its row afterwards and open Auvik site scope. Clear Include every accessible site, choose Load Auvik sites, tick the sites, then choose Verify & save settings. Ticking a site does not save it on its own. Exact site IDs accepts up to 25 comma-separated leaf-site IDs instead. Changing the region or username requires saving and verifying again before the site list will load.
5. Save the blueprint and open the relevant stratum's Continuum Link controls from its + Add tab menu. Search by device name, IP address, serial number or stable Auvik API ID and review the site, identity and matching evidence before linking. Suggest integrations… on a shape and Scan for integrations across the blueprint both offer candidates; selecting one is still an editor decision.

Include every accessible site includes current and future sites accessible to the Auvik service account. Clear it and select exact sites to keep a connection focused on one customer or environment. The list uses Auvik's site labels or domain prefixes alongside stable IDs. Selecting a parent organisation is not a substitute for selecting its leaf sites. Device names and private IP addresses can repeat across sites: check the site and stable device ID before attaching a panel.

Verification checks inventory and alert access for each explicitly selected site. Optional capabilities are checked on one representative site; the result names that site. The first fetch and later refreshes check the actual linked device and available data, so a verified connection can still have unavailable optional observations on another device or site.

Choose the saved information

Setting	Default	What it changes
Auvik snapshot audience	Blueprint editors	Keeps the imported panel visible to blueprint editors. Choose All Blueprint readers only after approving the information for everyone who can read the blueprint. Unlike Datadog, LogicMonitor and Rootly, Auvik's reader option carries no "approved metadata" suffix.
Saved detail	Summary	Keeps device and site identity, monitoring state, hardware, firmware and event counts. Detailed mode also permits internal IP addresses, serial numbers, network identities and alert names; review the resulting preview before sharing it.
Interfaces and connected peers	Off	Adds counts of disabled or impaired interfaces and history for up to two selected enabled interfaces with known peers. Detailed mode also shows up to 12 important interfaces with available peer and network relationships. Requires read access to API – Interface info.
Maintenance context	Off	Adds available running-configuration backup metadata and lifecycle context. Requires the corresponding device-detail and hardware-lifecycle reads. Configuration bodies are not imported.
Performance summary	Off	Adds device availability and outage plus interface utilisation and discard observations over the previous 24 complete UTC hours. The Auvik account must expose the statistics and the service account must be permitted to read them.
Alert history period	7 days	Chooses a 1, 7 or 30-day history window. This does not define which alerts are currently active.

Optional sections can be unavailable because of account permissions, discovery coverage or product availability. They do not require write access. Ask the Auvik administrator to grant the specific read permission or leave the section off; granting an administrative role is unnecessary.

Read the panel in context

The device status is Auvik's observation at the fetch time. An online device can still have a fault, and a device marked unmanaged is not evidence of monitoring coverage. Missing information means unknown or unavailable, not healthy.

Alert history contains events that Auvik recorded during the selected window. Created, resolved, paused and unpaused events retain their meanings. A created event is not presented as proof that its alert is still active. Dismissal and dispatch are separate properties. Use the event's source link to check the current record in Auvik when using Detailed mode; Summary retains event counts and the device's dashboard link. The detailed timeline shows the most recent 20 retrieved events, and the scope states which interfaces were included. Detailed mode also caps the network membership table at 20 networks and the address list at 12, each with a coverage row stating what was omitted.

Interfaces distinguish whether a port is administratively enabled from its observed operational state. An administratively disabled port is different from a failed uplink. Peer and network relationships describe Auvik's discovered inventory; they do not establish that a route is reachable or that redundancy will work.

Maintenance information helps prepare a replacement or change. A backup timestamp does not prove that a restore will succeed. Lifecycle information can include Auvik's information provider, confidence and source links; review those sources before treating a predicted end-of-support date as a vendor commitment.

Performance observations cover the previous 24 complete UTC hours with hourly samples. The panel states its period and units; missing hours remain gaps, and an hourly average is not an instantaneous measurement or a service availability guarantee.

Refresh and recover

Opening the tab shows its saved snapshot. Re-fetch with the circular-arrows icon on the linked row ("Re-fetch this integration's data"). After five minutes the snapshot is due for refresh; this is a reminder, not automatic polling. A failed refresh retains the previous snapshot with a warning. An unreadable or incomplete optional section is labelled rather than turned into zero alerts or a successful check.

If access fails, check the account's API role, selected sites and region. An Auvik account move can require a new region. Unlink every linked Auvik device before changing it: "Unlink existing Auvik devices before changing region, then review and link their identities in the new region." For a rate limit, wait before refreshing again.

Choose Rotate token on the connection's row, then Verify & replace, which verifies a replacement credential before it swaps. A replacement is refused when more than 50 linked Auvik identities need checking; move some links to another verified connection first. Suspend stops search and refresh while leaving snapshots readable, and the broken-link icon removes the current binding. Delete a connection after removing its bindings.

Site or credential changes must preserve access to existing links. If a new scope excludes a linked site, keep it selected or unlink that device first. Older links without a saved site identity need to be reviewed and linked again before their scope or credential identity can change.

Sharing and retained copies

The panel is fetched with the service account's access. Readers do not need their own Auvik account to see an approved reader-visible snapshot. Opening a source link still requires their own Auvik access.

Editor-only panels use Blueprintr's existing audience controls for readers, embeds, viewer exports and search or AI indexing. Approved reader-visible content follows the blueprint's audience, including the public on a public blueprint. Editor exports and backups can retain the source information.

Settings apply to later fetches. Restricting the audience does not rewrite panels already saved: refresh each linked tab successfully, or unlink it, before treating existing Auvik content as editor-only. Settings do not retract previous exports, version history, templates or other independent copies, or redact authored titles and notes outside the managed panel. Revoking a key, suspending a connection or unlinking does not recall existing copies.

Before operational use, compare a known device and its history with your own Auvik account, confirm the selected sites and optional permissions, and check the reader view. Some Auvik API capabilities are documented as beta. Local tests do not establish your account's access or live data completeness.

Link a ServiceNow configuration item (CI) to the stratum for the component it records. The saved tab shows what the CMDB believes about that component: its class, lifecycle, environment, the groups that own and support it, when Discovery last saw it, how it relates to other CIs and, if you choose, the open incidents and changes recorded against it. Changing the record stays in ServiceNow.

Any record in cmdb_ci or a class that extends it can be linked: servers, network gear, application services, business applications. IP-address and network-adapter records are found too, but rank below the device with the same name.

Connect

1. You need an Enterprise licence, edit access to the blueprint, and continuum_integrations.manage on the connection's organisation or team.
2. In ServiceNow, create a dedicated integration user. Give it the cmdb_read role, which reads every CMDB table. If the instance enables the REST API ACL, add snc_platform_rest_api_access as well. Tick Web service access only on the user, and keep it out of any policy that demands interactive multi-factor authentication: the connection signs in with the password on every call and cannot answer a prompt.
3. In Blueprintr, open Settings → Continuum on the organisation or team, go to Operational integrations, choose New integration, and select ServiceNow CMDB as the Type.
4. Enter the Instance URL (https://acme.service-now.com, reachable from the public internet), the Username, and the password, set the options below, and choose Connect & verify.

Connection options

Each dropdown opens on Use default, which stores the first option.

Field	Options	Effect
Snapshot audience	Blueprint editors (recommended), All Blueprint readers	Who can read the saved tab. Readers includes anonymous readers, embeds and exports on a public blueprint
Saved detail	Detailed (default), Summary	Summary withholds the IP address, FQDN, MAC address, serial number, asset tag, location and description from the tab and from its saved data
Open work	Not imported (default), Open incidents and changes	Adds open incident and change counts for the CI, with the five newest task numbers and links to the filtered lists

Verification reads one record from each table the connection will use: cmdb_ci, cmdb_rel_ci, and with open work switched on, incident and change_request. A table the user cannot read fails verification with its name and the role that grants it, for example "The ServiceNow account cannot read cmdb_rel_ci (HTTP 403 Forbidden). Grant cmdb_read, plus snc_platform_rest_api_access when the REST API ACL is enabled."

Open work needs sn_incident_read and sn_change_read from the ITSM Roles plugin, or itil. Those roles may count as a fulfiller licence on your instance; check with your account team before granting them.

On a domain-separated instance the user sees only its own domain, and so does the tab.

Link a configuration item

Open the stratum and choose Continuum Link, then search by any of these.

What you type	What happens
A name, FQDN, serial number or asset tag	Substring match on those four columns, up to 20 results
An IP address	Exact match on the CI's IP address column, plus a name match
A MAC address, with colons or hyphens	Exact match on the MAC address column in either form
A 32-character sys_id	The record itself

Each result shows its class, IP address, location and lifecycle, so two records with the same name can be told apart, and its sys_id in the preview.

Scan and Suggest resolve hostnames, FQDNs, IP addresses, serial numbers and MAC addresses from the diagram. Identifiers of one kind are folded into a single query of up to 50, so a full site drawing costs a handful of reads.

What the panel shows

Section	Contents
Configuration item	Name, class, environment, classification, lifecycle stage, install status, operational status, model, manufacturer, and in Detailed mode the location, FQDN, IP address, MAC address, serial number, asset tag and description, then the record's last update in UTC
Ownership	Support group, managed-by group and change group. People are never imported
Discovery and attestation	When Discovery last and first saw the record and from which source, or "Never", and the attestation status and date
Open work	With open work switched on: open incident and change counts, then the five newest of each with priority, state and a link
Relationships	Up to 25 relationships as seen from this CI ("Depends on", "Used by", "Located in"), with the other CI's name and class, and the total when there are more
In ServiceNow	Links to the record's own form, the Dependency Views map and, with open work on, the filtered incident and change lists

The headline reads the install status and operational status together, for example "Installed · Operational". ServiceNow keeps the two fields independently, so a record retired through install status is shown with a warning even while its operational status still says Operational. On order, in stock, in maintenance, repair, standby and ready states are shown as informational. The CSDM lifecycle stage appears as its own row.

Environment is the record's own environment field. Older records that only set the legacy "Used for" field show that value instead.

Dates come from the stored value and are labelled UTC. If an instance returns only display values, the date is shown as ServiceNow formatted it, without a zone label.

Counting and its limits

Relationships stop at 25; the section title then reads "Relationships (25 of 61)". Open incidents and changes are read up to 25 each; the count states how many were retrieved when the total is higher.

What is never imported

Person fields (owned by, managed by, assigned to, attested by), comments, work notes, incident and change descriptions, and any custom column. Only the named columns are requested, and the saved data is projected from them, so a column the instance returns anyway never reaches the blueprint.

Audience

New connections save snapshots for blueprint editors only. Choose All Blueprint readers only when the class, ownership, relationships and, in Detailed mode, the addresses and serials are appropriate for everyone who can read the blueprint. Changing the audience applies to later refreshes and does not recall copies already shared, exported or answered by AI.

Refreshing and recovery

Snapshots become due for refresh after one day, which is a reminder rather than automatic polling. A failed CI read keeps the previous snapshot and adds a warning. A relationship read or task read that fails marks the panel incomplete and says which table could not be read; the rest of the panel still saves. A rate limit answered by ServiceNow with Retry-After is reported with the number of seconds and is never retried in a loop.

Continuum Local is an agent you run inside your own network. It exists so Continuum Link can read monitoring systems that are never exposed to the internet.

It is the on-premise half of Continuum Link and sits behind the same gate: an Enterprise licence and continuum_integrations.manage on the organisation or team.

What it serves

Seven connectors: SolarWinds Orion, Zabbix, PRTG Network Monitor, Checkmk, Icinga 2, ManageEngine OpManager and WhatsUp Gold. Each appears in the connector list but stays disabled, reading "Needs a Continuum Local agent", until your organisation has an agent that is enrolled and online. An agent counts as online when it has checked in within about ninety seconds.

How it reaches Blueprintr

The agent dials out. It long-polls Blueprintr over TLS, claims queued work, executes it against systems on your network, and posts the results back on a later poll. Nothing connects inward, so no inbound firewall rule is needed.

There is no schedule of its own. A job is created when an editor refreshes a linked tab, and a queued job expires if no agent claims it.

Credentials stay on your network

Credentials for your on-premise systems are held in the agent's own configuration file and are never sent to Blueprintr. The connection form for an agent-backed connector has no credential field at all; it says "Credentials stay on your network" in its place.

Blueprintr runs the connector with unguessable placeholder values standing in for the credential, and tells the agent which parts to replace with local values. The agent refuses to send a request if a placeholder survives into it.

Blueprintr therefore cannot read, export or recover those credentials, and cannot help you rotate them. Rotation happens in the agent's configuration and in the monitored system.

Connector	Credential parts in the agent config
SolarWinds Orion	username and password
Checkmk	username and password
Icinga 2	username and password
WhatsUp Gold	username and password
Zabbix	token
PRTG Network Monitor	token
ManageEngine OpManager	token

For SolarWinds Orion, Checkmk and Icinga 2 the username typed into the connection form is replaced by the agent's own at dispatch, so set it in the agent config.

Registering an agent

Register it yourself from Settings → Continuum → Continuum Local on the organisation or team.

New token and Re-enroll mint a replacement, which burns the previous one. Revoke cuts an agent off. An enrolled agent that does not advertise HTTP relay shows "Does not advertise HTTP relay", meaning it needs upgrading.

Compatibility

The agent advertises what it can do, and Blueprintr sends only work that matches. A newer kind of job is invisible to an older agent rather than breaking it, so agents upgrade on your schedule rather than Blueprintr's.

Certificates

A self-signed certificate is a frequent cause of a failed on-premise connection. Orion, PRTG, Checkmk, Icinga 2, OpManager and WhatsUp Gold all ship one. Point the agent at your certificate authority file rather than disabling certificate checking.

Getting the agent