Relationships Explorer

The Relationships Explorer at /relationships renders your infrastructure as an interactive graph, making it possible to see how configuration items connect across sources and types at a glance. Instead of reading through tables of relationships one CI at a time, the explorer lets you select a set of starting CIs, expand outward by configurable depth, and interact with the resulting network visually.

This is particularly useful for understanding blast radius before maintenance, tracing dependency chains across source boundaries, and discovering unexpected connections between infrastructure components.

Two-Phase Workflow

The Relationships Explorer follows a deliberate two-phase approach: first you narrow down which CIs you care about, then the graph expands outward from those CIs to reveal their connections.

Phase 1: Filtering

The filter phase uses the same search and filter system as the CI list page. You can type structured queries like source:kubernetes or type:pod, use quick filter chips, or combine multiple filters to narrow the result set. The CIs that match your filters become the seed nodes for the graph. See Searching and Filtering CIs for full filter syntax documentation.

Keeping your seed set focused is the single most important factor in producing a readable graph. Starting with a narrow filter (a specific namespace, a single host, or a handful of services) produces a graph you can actually interpret. Starting with hundreds of unfiltered CIs produces a dense hairball.

Phase 2: Graph Expansion

Once seeds are selected, the explorer traverses outward from each seed node. The depth parameter controls how many hops the traversal takes -- depth 1 returns only direct connections, depth 2 adds their connections, and depth 3 extends one level further. The resulting nodes and edges are rendered as an interactive graph.

The graph enforces a 500-node limit to maintain browser performance. When the traversal would exceed this limit, the result is truncated and a warning banner appears indicating that the graph is incomplete. If you hit this limit, narrow your seed filters or reduce the traversal depth.

Visual Encoding

The graph uses color, size, and labels to encode multiple dimensions of information simultaneously, so you can distinguish CI types, source systems, and relationship types without reading every label.

Nodes

Each node in the graph represents a single configuration item. Three visual properties encode its identity:

• Fill color represents the CI type. Colors are assigned consistently per CI type (e.g., kubernetes.pod), so pods are always the same color regardless of which cluster they belong to.

• Border color represents the source system. Kubernetes CIs have one border color, Proxmox another, Netbox another, and so on. This makes it easy to spot where source boundaries lie in the graph -- look for clusters of nodes with the same border color.

• Size distinguishes seed nodes from discovered nodes. Seed nodes (the CIs you filtered for) render at 70px diameter, while related nodes discovered during traversal render at 45px. This size difference makes it easy to locate your starting points within a large graph.

Edges

Edges represent relationships between CIs. Each edge is colored by its relationship type using the same consistent coloring approach as node fills -- all runs_on edges share one color, all contains edges share another, and so on. Edge labels are hidden by default to reduce visual clutter and appear on hover, showing the relationship type (e.g., runs_on, contains). This hover-to-reveal pattern keeps the graph readable at low zoom levels while still making relationship details accessible when needed.

Graph Controls

The control panel provides tools for adjusting depth, layout, and viewport.

Depth Slider

The depth slider controls how many hops the traversal takes from seed nodes. Changing depth triggers a new API call and re-renders the graph.

Higher depth values produce exponentially more nodes. A single Kubernetes node at depth 3 can easily produce hundreds of nodes as the traversal fans out through pods, services, deployments, and their own connections.

Layout Algorithms

Five layout algorithms are available, each suited to different graph shapes and analysis goals.

You can switch between layouts at any time without losing the current data. The graph re-arranges nodes according to the new algorithm while preserving all node and edge information.

Viewport Controls

• Zoom in / out -- Buttons for incremental zoom adjustment
• Fit view -- Automatically zoom and pan to show all nodes in the viewport
• Reset -- Return to default zoom level and center position
• Mouse / trackpad -- Scroll to zoom (range 0.1x to 3x), click and drag to pan

Statistics

The control panel displays a live count of nodes and edges in the current graph. These numbers update as you change depth or filters, giving immediate feedback on graph complexity.

Interacting with the Graph

Node Interactions

Single click on any node opens a popover panel showing the CI's name, type, source system, and namespace. The popover includes a "View Details" link that navigates to the CI's full detail page at /configuration-items/{id}.

Double click on any node navigates directly to the CI's detail page, bypassing the popover. This is the fastest way to drill into a specific CI from the graph.

Edge Interactions

Single click on any edge opens a popover showing the relationship type, the source node name, and the target node name. This is useful for confirming the nature of a connection when the edge label alone is ambiguous.

Pan and Zoom

Click and drag on empty space to pan the viewport. Use the scroll wheel or trackpad pinch gesture to zoom in and out. The zoom range is constrained between 0.1x and 3x to prevent the graph from becoming unreadably small or large.

Relationship Types

The graph can display any relationship type that exists in Parascope. The most common types and their meanings are listed below.

Legend Panel

The legend panel provides a visual key for interpreting the graph. It is organized into four sections:

• CI Types -- Each CI type present in the graph is shown with its fill color swatch and label. This lets you quickly identify what type a node represents without clicking on it.

• Sources -- Each source system is shown with its border color indicator. Since nodes use border color for source encoding, this section maps border colors back to source names.

• Relationship Types -- Each relationship type present in the graph is shown with its edge color swatch. This helps decode the meaning of colored edges at a glance.

• Node Size -- A visual comparison of seed node size (70px) versus related node size (45px), clarifying the size distinction in the graph.

URL State

The explorer persists its full state in URL query parameters, including the active filters, traversal depth, and selected layout algorithm. This means you can bookmark a specific graph view and return to it later, or share the URL with a colleague to show them exactly the same graph. Changing any control updates the URL in place without triggering a full page reload.

For example, a URL like /relationships?source=kubernetes&depth=2&layout=dagre would open the explorer with Kubernetes CIs as seeds, depth 2 traversal, and the hierarchical layout pre-selected. This makes it straightforward to create saved bookmarks for common analysis patterns.

RBAC and Restricted Nodes

The Relationships Explorer respects data scope restrictions configured through role-based access control. When a traversal reaches a CI that falls outside your data scope, the node still appears in the graph -- since removing it entirely would break the visible topology and hide legitimate connections -- but is rendered as a [Restricted] placeholder. Restricted nodes show no identifying information: no name, no type-specific data, and no clickable detail link. They appear as dimmed, generic nodes that indicate "something exists here" without revealing what it is. This preserves the structural integrity of the graph while enforcing access boundaries.

See RBAC Administration for more on configuring data scopes.

CI Detail Page Integration

The Relationships Explorer is not the only place to view relationships as a graph. Every CI detail page at /configuration-items/{id} includes a Relationships tab with both a table view and a graph view focused on that single CI. The detail page graph is essentially the Relationships Explorer scoped to a single seed node, with the same graph rendering, layout options, and interaction patterns. Use the detail page graph for single-CI exploration and the full Relationships Explorer page when you need to start from multiple seed CIs or perform broader network analysis.

Example: Pre-Maintenance Impact Analysis

Consider a scenario where you need to take a Proxmox hypervisor offline for maintenance and want to understand the full impact. Here is how you would use the Relationships Explorer to answer that question.

First, in the filter phase, enter type:proxmox.node name:host-01 to select the specific hypervisor as your sole seed node. Set the depth to 2 so the graph expands through VMs and into the workloads running on those VMs. Choose the hierarchical (Dagre) layout so the result reads as a top-down dependency tree.

The resulting graph shows host-01 at the top with runs_on edges descending to its three VMs. Each VM in turn has edges descending to Kubernetes nodes, OS instances, pods, and services. At a glance you can see that this hypervisor supports 3 VMs, 2 Kubernetes worker nodes, 14 pods, and a DNS server. The radial layout would show the same information organized as concentric rings, making the blast radius even more visually apparent.

Single-clicking the DNS server node reveals it hosts a dns.zone for example.com -- information that would take several navigation steps to discover through the CI list alone. Double-clicking any pod takes you directly to its detail page for deeper investigation.

Tips for Effective Exploration

Start with specific filters. The most common mistake is loading the explorer with no filters, which tries to graph your entire infrastructure. Begin with a specific source, type, namespace, or name filter to keep the seed set manageable.

Use hierarchical layout for infrastructure stacks. When exploring vertical relationships like pod-to-node-to-VM-to-host, the Dagre hierarchical layout arranges nodes in a top-down tree that naturally mirrors the infrastructure hierarchy.

Use radial layout for blast radius analysis. To understand what a single CI affects, filter to that CI alone, set depth to 2 or 3, and switch to the concentric radial layout. The seed CI sits at the center with affected CIs arranged in rings by distance, giving an immediate visual sense of the blast radius.

Reduce depth before expanding filters. If your graph is too dense, try reducing depth to 1 before removing filters. Depth 1 shows only direct connections, which is often sufficient for understanding a CI's immediate neighborhood.

Double-click to drill in. When you spot an interesting node in the graph, double-click it to jump to its detail page. From there, the detail page's own relationship graph lets you explore further from that new starting point.

Watch the node count. Keep an eye on the node and edge statistics in the control panel. Graphs beyond 200 nodes become difficult to interpret visually. If you approach the 500-node truncation limit, narrow your approach.

Related Documentation

• Searching and Filtering CIs -- Filter syntax used in the seed selection phase
• CI Details -- Single-CI detail page with its own relationship graph
• Infrastructure Lineage -- Vertical lineage tracing through infrastructure tiers
• Correlation Engine -- Creates cross-system relationships visible in the graph
• API Reference -- Full API documentation including the graph endpoint