Authoring topologies

Creating a view

From the Topology Studio landing page, click Create topology view:

• View ID — type freely; the identifier is derived automatically from what you enter. It is unique and cannot be changed later, so it is worth a moment’s thought — it is what deep links and exports refer to.

• Display name — the label shown on the card, the canvas and in alert emails.

• Description — optional, free text.

• Category — optional grouping label (for example Production). Views sharing a category are grouped under one heading on the landing page.

• Can view (roles) — read-only access.

• Can edit (roles) — roles allowed to modify or delete the view.

Two guarantees are built into the role lists, so you cannot lock yourself out: administrators always have access regardless of what is listed, and the view’s creator always keeps edit access. Roles with edit access can always view, so they need not be repeated in the view list.

Important

A role listed under Can edit still needs TrackMe power permissions to author. Granting edit to a user-tier role does not promote it — such a role remains read-only either way. See Administration.

The new view opens directly on the canvas editor.

The canvas editor

The editor is a direct-manipulation canvas: drag nodes to place them, click to inspect, right-click for context menus. The essential mechanics:

• Explicit Save. Nothing is persisted until you click Save — you can experiment freely. The editor warns before you navigate away with unsaved changes, and Undo (the button, or the universal Ctrl/Cmd+Z) reverts the last 25 structural operations.

• Conflict detection. If someone else saved the view while you were editing, Save is refused and you choose between reloading their version or overwriting it — no silent lost updates.

• Multi-select and group moves. Modifier-click (or select-all) selects several nodes at once — drag any one of them and the whole group moves together, with a live preview of where every companion will land. Bulk deletion works on the same selection.

• Escape releases. Grabbed a node (or a group) and changed your mind? Escape releases it back where it was — the drop never happens and no undo step is consumed. Undo remains the tool for a move that already landed.

• Auto-arrange. One click computes a hierarchical top-down layout from your edges: roots on top, children in collision-aware rows beneath their parents, the canvas growing as needed for readable spacing. Use it as a starting point, then refine by hand — like everything else it only persists when you Save.

• No practical size limits. Author maps as large as your environment demands — there is no cap on the number of entities, aggregates or labels in a view. The only guard is a generous storage-size backstop that no hand-authored map approaches.

Version history and rollback

Every Save automatically snapshots the previous state of the view, so each view carries its own version history: open it from the canvas toolbar to list the versions (who saved, when, and from which action), preview any version’s graph, and restore one. Restore is non-destructive — the state you are replacing is snapshotted too, so a rollback is itself reversible. Broke the map at 5 pm? Go back to how it was at noon in two clicks.

Adding entity nodes

Add entity opens a cross-tenant picker: choose a tenant and a component, search, and multi-select the entities to place. Any entity from any tenant and any of the six components (DSM, DHM, MHM, FLX, FQM, WLK) can join the same map — this is where cross-domain dependency maps come from (the data source and the host and the workload that produce a service, side by side).

New nodes land collision-aware near the canvas center, ready to be dragged into place.

Entity KPIs

Each entity node can display up to five KPIs, stacked as on-canvas displays next to the node — the numbers you want visible at a glance:

• DSM / DHM / MHM / WLK offer a fixed, typed KPI catalog (lag, latency, event volume, host counts, skip percentage, execution errors…).

• FLX, FQM and WLK additionally expose the entity’s own metrics: whatever the entity reports in its metrics payload becomes selectable as a KPI — for Flex Objects this means your custom KPIs land on the map (WLK is hybrid: catalog first, metrics on top).

The node chooses one display style applied to its whole KPI stack: a themed stat card, a card-free colored value, a compact status badge, or a sparkline (label, value and a 24h mini trend line — see below); aggregate nodes additionally offer a health donut (their member-state distribution — a display only an aggregate can have). Every KPI in the stack can carry its own short label replacing the technical metric name — rename each one independently.

Sparkline KPIs — trends over time, at scale

The Sparkline display style (TrackMe 2.4.13+) turns each selected KPI into a label, its current value, and a 24-hour mini trend line drawn right on the canvas — the same at-a-glance history the entity inspector’s Metrics (24h) panel shows, now visible for every node you choose without opening anything.

Sparklines are designed to be safe at any view size: no matter how many nodes carry the style, the whole view’s trend history is fetched by one single batched metrics search, refreshed every few minutes on its own schedule. The KPI value keeps updating with every live-status refresh — only the trend shape follows the slower cadence. A KPI without enough recorded history shows a dashed placeholder line instead of a trend, and PNG exports draw the real trend lines. In Topology Alert emails, sparkline-styled KPIs render as stat cards (the email has no live history at generation time).

The style is available for entity nodes and for the auto-generated members of an expanded aggregate (via the aggregate’s member KPI defaults). Aggregate nodes keep their own display choices (card, value, badge, donut).

Adding aggregate nodes

An aggregate node rolls up many entities into one node: pick one or more tenant/component scopes (up to 8 pairs) and optionally a filter expression — the same filter grammar used by Virtual Groups (field=value with wildcards, OR / AND, parentheses). By default the node folds to the worst state of everything it matches and shows per-state counts; alternatively, an aggregate can opt into a healthy-percentage policy — you set the orange and green thresholds, and the node classifies by the percentage of healthy members instead of the single worst one (the right semantics for large fleets where one red host should not paint a 500-strong aggregate red).

The modal’s preview shows the roll-up and lists the matching entities themselves, so you verify the filter selected the right entities — not just the right number — before you commit. Add as many aggregates as your map needs: there is no per-view limit.

An existing aggregate’s scope and filter can be edited in place at any time (right-click → Update scope): the node keeps its identity, position, edges, KPIs and member layout — only the membership definition changes.

Auto-populated aggregates

An aggregate can also expand: its current members (up to 50, a limit you control per aggregate) appear as satellite nodes linked around it. Membership is dynamic — entities that newly match the scope join the map on their own, entities that stop matching leave it — and the positions you give individual members are remembered. Individual members can carry a custom label and icon, and the aggregate can set default KPIs (up to five, each renamable) displayed on every member node at once — one setting instead of fifty. The picker is pre-populated from the scope’s own component catalogs, and the same values appear on the canvas, in the inspector and in the server-rendered alert emails. This is the “self-maintaining” corner of a map: author the aggregate once, and the topology follows reality.

Auto-generated members can also join your dependency map directly: connecting an edge to one pins it — the member becomes a permanent entity node (keeping its name, icon and position, still linked to its aggregate), so membership changes no longer remove it and your edges stay valid. Search finds them, KPIs follow them, and the alert email renders them exactly once.

Labels, icons and background

• Label nodes are free-text annotations with color control — name your zones, tiers and flows.

• Node icons: pick from a catalog of 74 icons with keyword search (databases, networks, clouds, applications, pipelines…). The same icons appear in the server-rendered alert emails.

• Custom icons: upload your own images — vendor logos, team emblems, product marks. TrackMe normalizes any picked image into a crisp square icon and stores it in a deployment-wide catalog: upload once, and every author sees it in the picker (a Custom section with live thumbnails) across every view. Uploads are validated server-side (PNG/JPEG, size and pixel-dimension caps), and a deleted custom icon degrades gracefully — nodes fall back to their default glyph, nothing breaks.

• Background image: upload a PNG or JPEG (up to 2 MB) as the canvas backdrop — a regional map, an architecture diagram, a site plan — with fit (cover/contain) and dim controls so node colors stay readable.

Beyond labels and backgrounds, the canvas can carry free-floating decorations — shapes, images and text drawn directly on the map (TrackMe 2.4.14+). They have their own page: Decorations and canvas layout.

Connecting nodes — edges

Toggle Connect mode, click a source node, then click a target: the link is drawn and saved with a one-way source → target relationship by default. Links are what turn a set of nodes into a dependency map — and they are also what top-down auto-arrange, live impact propagation and alert rendering follow.

Select a saved link on the canvas, right-click it, or open it from a node’s Connections list to manage it in the link inspector. The inspector shows the stored Source and Target explicitly and lets you:

• choose One way (→) — show an arrow at the target and propagate from the stored source to the stored target;

• choose Bidirectional (↔) — show arrows at both ends and allow propagation in either direction;

• choose No direction (—) — hide the arrowheads while retaining the stored source-to-target propagation direction;

• Reverse source and target for a one-way or hidden-arrow link;

• select the link for impact propagation, add an optional label, or remove it.

Reversal is disabled while a link is bidirectional because both ends are already visually equivalent. Choose One way or No direction first when you really need to swap the stored endpoints. Reversal also clears Select this link for impact propagation: that selection belonged to the old source, so enable it again only if the new source should use the reversed relationship.

Automatically generated aggregate-member links are intentionally different: they are one-way, read-only links owned by aggregate expansion. Configure the aggregate rather than the generated link.

Impact propagation

A dependency map can do more than show colours side by side — it can propagate any non-green status onto the nodes that depend on it. Red is bad, orange is a warning, and blue is informational; only green means good and therefore does not propagate. The inherited status becomes the target’s effective canvas and Topology Alert status, while its own native status is retained for explanation.

Choose the propagation mode in the source node’s Impact propagation section:

• Do not propagate — the default; the node’s status remains local.

• Propagate through selected links — reflect the node’s native non-green status one hop across every link whose Select this link for impact propagation switch is enabled. You may select several links.

• Propagate through all downstream links — follow every reachable relationship, transitively, for “if this fails, everything below it is affected” semantics. Link selection is not required in this mode.

Direction remains significant. One-way and hidden-arrow links propagate from their stored source to their stored target. A bidirectional link contributes both paths, so either endpoint can affect the other immediately when its node mode permits it. On a selected bidirectional link, the selection applies from either endpoint. Cycles are safe and terminate automatically.

An inherited status does not become a new source by itself. Selected links stays a one-hop operation even when the target also has propagation enabled; use all downstream links when the intended impact must cross the whole chain.

Status conflicts are resolved without hiding a more important local condition. For propagation precedence only, red outranks orange, orange outranks informational blue, and blue outranks good/green. An equal or higher native status therefore remains the target’s own truth. Blue is still distinct from healthy green: a blue source can repaint a green target blue, but it does not open an alert.

Protected or maintenance-blue entities and nodes whose state is unknown are never repainted. A blue aggregate is the deliberate exception because its blue is only the derived roll-up of its members, not maintenance applied to the aggregate itself. A higher-precedence red or orange dependency may therefore repaint the aggregate while its native blue roll-up remains visible in the explanation.

Every repainted node identifies the cause in its inspector and reports its native status alongside the inherited one. The same effective status and attribution are used by Topology Alerts and their email details: red alerts, orange follows the alert’s warning setting, and blue remains informational.

Consuming a view

Open a view and it is live: status polls every 60 seconds, with the last-updated time and an honest countdown to the next refresh displayed under the header controls, plus a manual refresh and a pause toggle. Clicking a node opens the inspector — live state, per-metric sparklines for entities, a mini-map of members for aggregates, and a one-click jump to the entity’s full Entity Overview in Tenant Home.

The aggregate mini-map is interactive: set how many members it shows (1–50), and click any member dot — mouse or keyboard — to preview that member’s state, name and tenant inline; on an expanded aggregate, Open node jumps straight to the member’s own node and inspector.

For consumption at scale:

• Canvas search — a keyword box in the header finds nodes by label, entity name, tenant, component, or an aggregate’s scope and filter — matches light up with halo rings on the canvas, Enter cycles through them (selecting each node and panning it into view), Esc clears. On a large map, this is how you find the node you just added — or the one that’s red.

• Deep links — every view has a bookmarkable URL; share the link, land on the map.

• Full-screen mode — a chrome-free rendering for a wall of screens, addressable directly by URL parameter so a kiosk browser can boot straight into it.

• KPI visibility, also by URL — the toolbar’s Show / Hide KPIs toggle controls the on-canvas displays, and the choice is URL-addressable too (&show_kpis=1 or &show_kpis=0): decide per screen what a kiosk shows, even though full-screen hides the toolbar. A complete wall-screen URL: ?view=<id>&fullscreen=1&show_kpis=0.

• PNG export — one click captures the current canvas as an image for slides and incident timelines.