A CMDB without relationships is a flat asset list. Add relationships and you can answer “what fails if this server goes down.” Add too many and the graph becomes unreadable. The middle path requires deliberate modeling.
Relationship types
Freshservice ships with: Depends on / Used by, Connected to / Connected from, Member of / Has member, Manages / Managed by, Hosts / Hosted on, Runs on / Runs.
Pick three to four for your starting model. More confuses agents and creates inconsistent graphs.
Recommended starter set:
- Depends on / Used by (logical service dependencies).
- Hosts / Hosted on (physical or virtual hosting).
- Connected to / Connected from (network or integration links).
Add Member of / Has member when you start grouping (cluster nodes, load balancer pool members).
Relationship granularity
Two extremes are wrong:
- Too coarse: “App A depends on All Infrastructure.” Useless for impact analysis.
- Too fine: “App A’s auth service depends on DB1 connection pool member 7.” Impossible to maintain.
The right level: app-to-database, app-to-cache, app-to-load-balancer. One layer of indirection from the consumer.
Auto-discovered vs manual relationships
Probe discovery creates Hosts / Hosted on relationships automatically (VM on hypervisor, container on host). It does not create logical dependencies (App A uses Database B).
Build logical relationships manually or via integration with your APM (DataDog, New Relic). The APM knows the actual call graph; ingest it into Freshservice via API on a daily sync.
Direction matters
Relationships are directional even when bidirectional. “App A depends on DB1” is different from “DB1 used by App A” in queries. The CMDB shows both, but the impact analysis traverses one direction.
Convention: dependency arrows point from consumer to provider. App points to DB, frontend points to API, deployment points to cluster.
Impact analysis
Selecting an asset and clicking “Impact Analysis” walks the relationship graph. By default it walks “Used by” relationships outward. A failed database shows all apps using it, all customers using those apps.
Configure the impact analysis depth: 2 hops is fast and useful, 4 hops is slow and noisy. Anything beyond 4 hops should be a separate dependency-mapping tool, not Freshservice.
Keeping the graph clean
Stale relationships are worse than missing relationships. They mislead. Build a quarterly review: relationships untouched in 12 months get flagged. Owner confirms or removes.
Auto-decommission: when an asset is retired, its relationships should auto-mark for review, not auto-delete. Auto-delete loses history; the review keeps trail.
Querying relationships
The API supports filtering by relationship: /api/cmdb_assets?related_to=<asset_id>. Use this for integration with monitoring; an alert on DB1 can pull the list of dependent apps and route to all owners.
For complex queries (transitive dependencies, shortest path), export the graph and use a graph database (Neo4j, ArangoDB) for ad-hoc analysis. Freshservice CMDB is for source-of-truth, not graph analytics.
Visualization
The dependency map view renders a node-link diagram. Beyond about 50 nodes, the layout becomes unreadable. Filter by relationship type and depth before sharing screenshots in change reviews.
For exec presentations, capture the small core graph (tier-1 apps and their direct dependencies) and annotate. The full graph is for engineers, not executives.
What to do this week
Pick your three most critical applications. Confirm each has at least one “depends on” relationship pointing at its database. If not, add the relationship and run impact analysis. Share the result with the app team to validate.
