New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
IT service management
A lightweight CMDB that shows what depends on what
Map configuration items and their relationships so you can see what depends on what — a lightweight CMDB that ties assets, services and incidents together.
IT Assets · 1,284 tracked
MacBook Pro 14"
SN: C02XK3...
Aditi Singh
Active
Adobe Creative Cloud
42 seats · ₹4,200/mo
Design team
Active
Dell OptiPlex 7090
Warranty expires in 23d
Reception
Alert
Product proof
Already live in the product
Backed by app modules
Running in production today: configuration items and their relationships, tracked in the ITSM suite.
Protected app route: /itsm
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Configuration items
Dependency relationships
Linked to assets and incidents
Impact context for changes
Workflow
What teams can do here
Step 1
Register configuration items
Step 2
Map relationships
Step 3
See impact before a change
Step 4
Investigate incidents faster
How it works
How it works
01
Treat assets as configuration items
Your existing IT assets act as configuration items (CIs). You can also keep component/CI-type masters — for example Hardware, Software or Network categories — as reusable reference data.
02
Map directional relationships
Record how CIs relate with typed, directional edges: depends_on, runs_on, hosts, connected_to, part_of, uses and backup_of. A relationship reads source → (type) → target, e.g. "App server → runs_on → VM" or "Service → depends_on → Database".
03
Run impact analysis
Ask "what breaks if this CI goes down?" The impact analysis walks the dependency edges upstream — depends_on, runs_on, uses, part_of, connected_to — up to a bounded depth and returns every affected CI, with the path it followed.
04
Visualise the graph
A graph endpoint returns the full set of CI nodes and edges so the relationships can be rendered as a dependency map rather than read as a list.
Example
A worked example
Say a payments company with roughly 200 tracked CIs is about to patch its primary database. The change owner runs impact analysis on the database CI first. Because the billing service is mapped "depends_on" that database, and the customer portal is mapped "depends_on" the billing service, the walk returns both — surfacing that a "routine" restart would take the portal down two hops away, something no single relationship row showed. The patch is moved to a Sunday maintenance window, the two downstream service owners are told in advance, and the change record links the same CIs for the post-change review.
FAQ
Frequently asked questions
What kinds of relationships can we model?
Seven typed, directional relationships: depends_on, runs_on, hosts, connected_to, part_of, uses and backup_of. Direction matters — each edge points from a source CI to a target CI.
How does impact analysis decide what is affected?
Starting from the CI you name, it walks upstream along depends_on, runs_on, uses, part_of and connected_to edges — following who points at the CI — up to a bounded depth, and returns each affected CI along with the relationship it traversed.
What are the configuration items themselves?
CIs are your IT asset records, related to one another through the CMDB. That means the same assets you already track for inventory become the nodes in your dependency map.
Can the same two CIs have more than one relationship?
Each source–target–type combination is unique, so you cannot duplicate the exact same relationship, but two CIs can be connected by different relationship types where that genuinely applies — for example one server can both host a service and act as the backup_of another server.
Can we group CIs by type?
Yes. Alongside the relationships you can keep component/CI-type master records — such as Hardware, Software or Network categories — as reusable reference data, so configuration items are classified consistently across the organisation.
Can we see the dependencies as a diagram?
Yes. A graph endpoint returns all CI nodes and their edges so the relationships can be drawn as a visual dependency graph rather than read as a flat list of pairs.
How deep does impact analysis follow the chain?
It traverses several hops upstream up to a bounded depth, so multi-level dependencies (a service that depends on a service that depends on a server) are captured without the walk running away on a large graph.
Map assets into typed dependency relationships and run impact analysis up the chain — so a two-hop outage is discovered in planning, on the graph, not in production.