How to Create a CMDB in Freshservice
What Will This Guide Cover?
Before walking through the setup steps, here is a quick summary of what this article covers:
- Why a well-structured CMDB matters before you start adding configuration items
- How Freshservice ITSM Software relates to building and organizing a CMDB
- How to review and configure CI types to match your organization’s assets
- How to add configuration items manually and populate them with detail
- How to build relationships between CIs so dependencies stay visible
- Answers to frequently asked questions about creating a CMDB in Freshservice
How Does Freshservice Relate to Building a CMDB?
Freshservice ITSM Software includes a native Configuration Management Database, or CMDB, that acts as a central location for viewing every hardware and software item, known as a Configuration Item, or CI, across an organization’s network. Because Freshservice ships with a set of default CI types already covering common assets, such as laptops, workstations, network routers, and operating systems, IT teams do not need to design a CMDB structure entirely from scratch; instead, they configure and extend the existing framework to match their own environment.
This matters directly for anyone starting a CMDB project, since Freshservice reveals its value most clearly during this configuration phase. Rather than treating the CMDB as a flat list of assets, Freshservice links every CI to related requests, contracts, and activity history, while also supporting relationships between CIs so IT teams can see how one asset depends on another.
Why Does a Well-Structured CMDB Matter From the Start?
Before diving into configuration steps, it helps to understand why getting the structure right early makes a lasting difference.
What Happens When CI Types Do Not Match Real Assets?
When default CI types do not reflect an organization’s actual asset categories, technicians often force unrelated assets into generic categories just to get them into the system. This creates inconsistent records that make filtering, reporting, and automation far less reliable later, so reviewing and adjusting CI types before large-scale data entry begins saves considerable rework.
This problem tends to compound over time rather than staying isolated to a handful of records. Once technicians establish a habit of misclassifying assets to save time, that habit spreads across the team, and cleaning up hundreds of miscategorized records eventually takes far longer than pausing early on to define the right CI types in the first place.
How Does a Strong CMDB Support Other ITSM Processes?
A properly structured CMDB feeds directly into incident, problem, and change management, since every ticket can link back to a specific CI. This connection lets IT teams assess the impact of a proposed change before it goes live, rather than discovering hidden dependencies only after a system goes down.
Beyond change management, a well-organized CMDB also supports faster root cause analysis during incident investigations. When technicians can see exactly which CIs relate to an affected system, they spend less time manually tracing dependencies and more time actually resolving the underlying problem.
What Are the Core Steps to Create a CMDB in Freshservice?
Building a CMDB in Freshservice generally follows a logical sequence: review CI types, add configuration items, populate their details, and define relationships between them.
How Do You Review and Configure CI Types?
Freshservice comes with a set of default CI types that cover the essentials for a typical IT service desk, including hardware items like laptops and network routers, along with software assets like operating systems. Since the default assets or configuration items cannot be deleted, start by reviewing this existing list rather than trying to remove categories your organization does not use.
To add a new CI type when the defaults do not fit your needs, log in to Freshservice as an Account Admin, then navigate to Admin, then Asset Management, then Asset Types and Fields. From there, you can create additional CI types or edit existing ones so that every asset category in your organization has an appropriate home in the CMDB.
Which Fields Should You Define for Each CI Type?
Once a CI type exists, defining the right fields for it determines how useful that CI type becomes for reporting and automation. The table below outlines common field categories worth reviewing for most CI types.
| Field Category | Purpose | Example |
|---|---|---|
| Identification | Uniquely identify each CI | Display Name, Asset Tag, Serial Number |
| Classification | Group CIs consistently | Asset Type, Workspace, Impact |
| Ownership | Track responsibility | Used By, Managed By, Department |
| Lifecycle status | Track where a CI sits in its lifecycle | State (In Use, In Stock, Retired) |
| Cost and contracts | Support financial reporting | Purchase Cost, Associated Contracts |
Reviewing these fields for each CI type before adding large numbers of assets prevents gaps that would otherwise require going back and updating many records individually.
How Do You Manually Add a Configuration Item?
Adding a CI manually works well for assets outside your network, consumable items, or peripherals that automated discovery tools cannot detect. To add a CI manually, go to Assets, then Inventory, and click Add New. From there, enter the display name, asset tag, impact, and description, then select the relevant workspace and asset type, such as Hardware. Depending on the asset type selected, additional sections appear, such as Hardware Properties, Cost, and Assignment, where you can enter further relevant details before clicking Save.
This manual process becomes especially useful for maintaining visibility into items that would otherwise fall through the cracks, such as spare peripherals sitting in a storage closet or equipment loaned to remote employees who rarely connect to the corporate network. Keeping these items in the CMDB, even though discovery tools cannot detect them automatically, ensures the inventory reflects the organization’s complete asset footprint rather than only the portion visible through network scans.
Can You Attach Documentation to a Configuration Item?
Yes. While creating or editing an asset, Freshservice allows you to attach files and other documentation related to that CI, such as invoices, purchase orders, receipts, or proofs of purchase. Keeping this documentation attached directly to the relevant CI makes it far easier to reference during audits or warranty claims, rather than searching through separate folders or email threads later.
How Do Baseline Assets Help Maintain Consistency?
Freshservice also supports creating baseline assets, which represent the recommended configuration for a given CI type. For example, you might create a baseline Linux server CI that reflects the standard configuration your organization expects every Linux server to follow. Comparing updated asset records against this baseline later helps identify configuration drift before it becomes a larger operational problem.
How Do You Build Relationships Between Configuration Items?
A CMDB becomes significantly more useful once CIs are connected to one another, since these connections reveal dependencies that a flat list of assets cannot show on its own.
What Are Normal and Inverse Relationships?
Every CI in Freshservice supports two types of relationships: normal relationships and inverse relationships. Together, these relationship types build a comprehensive picture of how one asset ties to others in the organization, such as a server hosting a specific application or a network switch connecting to a set of workstations.
Understanding the distinction matters because a normal relationship viewed from one CI’s perspective typically has a corresponding inverse relationship when viewed from the connected CI’s perspective. For example, if a server “hosts” an application, that same application “runs on” the server. Freshservice captures both directions automatically once you define the relationship once, which keeps the CMDB consistent without requiring duplicate manual entries.
How Do You Add a Relationship to an Asset?
To add a relationship, log in to Freshservice as an administrator or technician, then navigate to the specific asset within the Asset Management module. From the asset’s Relationship tab, you can select another CI and define how the two are connected using one of Freshservice’s default relationship types.
Can You Create Custom Relationship Types?
Yes. In addition to the default relationship types Freshservice provides, administrators can create custom relationship types by going to Admin, then Relationship Types. This flexibility matters for organizations with dependency structures that do not fit neatly into the standard options, such as specialized hosting arrangements or custom application architectures.
What Should You Do to Keep the CMDB Accurate Over Time?
Creating the initial CMDB structure is only the starting point. A few ongoing practices help keep it useful well beyond the initial setup.
Why Should You Review the CMDB Periodically?
Since IT environments change constantly, as new hardware arrives and old systems get retired, scheduling a periodic review of CI types, fields, and relationships helps catch inconsistencies before they accumulate into a larger cleanup project. This review also gives teams a chance to confirm that new CI types created ad hoc during daily work still align with the overall structure.
How Do Discovery Tools Complement a Manually Built CMDB?
While this guide focuses on manually configuring CI types and adding assets, Freshservice also offers Discovery Agent and Discovery Probe tools that continuously update information about assets in real time. Pairing manual entries for peripherals and out-of-network assets with automated discovery for networked hardware gives the CMDB the most complete and current picture possible.
Conclusion
Creating a CMDB in Freshservice starts with reviewing the platform’s default CI types and adjusting them to reflect your organization’s actual assets, then adding configuration items manually where automated discovery cannot reach, and finally connecting those CIs through relationships that reveal real dependencies across your network. Taking time to define fields and baseline configurations early prevents the inconsistent records that often complicate reporting and automation later.
Freshservice ITSM Software supports this entire process with a centralized structure that links every CI to related requests, contracts, and activity history, giving IT teams a single, reliable source of truth rather than a scattered collection of spreadsheets. Attaching documentation directly to each CI, defining consistent baseline configurations, and mapping relationships between related assets all contribute to a CMDB that stays genuinely useful rather than becoming just another list of hardware nobody trusts.
Once the initial CMDB is in place, periodic reviews and complementary discovery tools help keep it accurate as your organization’s technology environment continues to grow and change. Approaching CMDB creation as an ongoing responsibility, rather than a one-time setup task, ultimately determines how much value the platform delivers across incident management, change planning, and everyday IT decision-making.
Frequently Asked Questions
No. The default assets or configuration items in Freshservice cannot be deleted, though you can add additional CI types or edit existing ones through Admin, then Asset Management, then Asset Types and Fields to better match your organization’s needs.
Not necessarily. Manual entry works best for assets outside your network, consumable items, and peripherals that discovery tools cannot detect. For networked hardware, Freshservice’s Discovery Agent and Discovery Probe tools can populate the CMDB automatically and keep records updated in real time.
Why Should I Bother Creating Relationships Between CIs?
Relationships reveal how assets depend on one another, such as which server hosts a particular application. This visibility helps IT teams assess the impact of a change before deploying it and speeds up root cause analysis when something in the environment breaks.
