CI Types
Out of the box: assets (hardware), software, services, contracts, locations, vendors, and users. You can extend with custom CI types — a Kubernetes Cluster CI with fields for cluster_id, region, node_count, and a relationship to the underlying cloud accounts. Build the type catalog before you bulk import; renaming a CI type after thousands of CIs exist requires a re-import path that breaks dashboards. Each CI type carries its own field schema, lifecycle states (in stock, in use, retired, disposed), and impact rules.
Discovery
Freshservice Probes (the on-network discovery agent) scan subnets via SNMP, WMI, and SSH, then push CIs back to the tenant via the discovery API. The Probe runs on Windows or Linux and needs outbound HTTPS to discovery.freshservice.com. Cloud Probes use IAM credentials to inventory AWS accounts (EC2, RDS, S3, IAM users), Azure subscriptions, and GCP projects on a 6-hour schedule. Automated population beats manual entry because manual data drifts within weeks. A typical first scan returns 3-5x the count of CIs the team expected — most are forgotten lab gear, expired test instances, or shadow IT.
Relationships
CI relationships model dependencies: depends on, hosted on, connects to, member of, and custom verbs. Service maps render these as graphs so a planned change to a database CI surfaces every service that runs on it. The API supports relationship queries:
// Find every service that depends on db-prod-01
fetch(`https://${domain}.freshservice.com/api/v2/cmdb/items?query="depends_on:'db-prod-01'"`, {
headers: { Authorization: 'Basic ' + btoa(`${apiKey}:X`) }
});Limit relationship depth to three hops in service maps — beyond three hops, the graph becomes unreadable and the impact analysis becomes meaningless.
Data Quality
Assign an owner per CI type (server team owns servers, app team owns applications, finance owns contracts). Quarterly review with the owner: stale CIs that haven’t been seen by discovery in 90 days, CIs missing required fields, CIs in in stock for over 180 days, and CIs with no relationships defined. Retire on decommission and don’t leave records floating — a CMDB with 40% retired-but-not-marked-retired CIs is worse than no CMDB because change risk reports become noise.
Integration
CMDB data informs change risk (a change touching a CI with 12 dependents auto-elevates to High risk), incident impact (an incident on a CI with downstream services auto-creates a major-incident workflow), and asset lifecycle (procurement creates a CI in in stock, deployment moves it to in use, retirement triggers reclaim of attached software licenses). Feed it well and CAB meetings stop being theatre.
Common Failure Modes
Three patterns. First, the “import everything and figure it out later” approach — without a curated CI type catalog, you end up with three flavors of Server CI from three discovery sources. Second, the relationship explosion — auto-discovered relationships balloon into thousands of weak links (an SNMP-discovered switch reports every MAC address it has ever seen as a connects to); cap auto-relationships and require a manual hosted on for impact analysis. Third, ignoring last_audited timestamps — without freshness tracking, a CMDB silently becomes a fossil within a year.
What Changed in 2026
Freshservice extended the AI-driven CI deduplication that Freddy now performs at ingestion. Rather than relying on exact-match keys, Freddy uses fuzzy matching on hostname + MAC + serial to merge duplicates from competing discovery sources, which dramatically reduces the manual cleanup pass after enabling a second probe.
What to do this week
Run a CI freshness report (CIs not updated in 90 days). Pick the top 20 by impact score and either re-validate them with the owner or mark them retired. The cycle is the discipline.
