CMDB setup is one of the most misunderstood projects in ITSM. Most organisations approach it as a data project. Get everything into a database and call it done. The organisations that have been through this know the reality: a CMDB built as a data collection exercise is inaccurate within six months, trusted by nobody and abandoned within twelve.
A CMDB that works captures the information your IT team needs to make better decisions about incidents, changes and problems. Nothing else. This guide covers what to think through before you start, how to scope it correctly, and how to build one that stays accurate and gets used.
What Is a CMDB and Why Does It Matter?
A Configuration Management Database is a structured repository of information about the IT assets and services that make up your technology environment. In ITIL 4, it sits within Service Configuration Management. Its purpose: give IT teams a reliable picture of what exists, how components relate to each other, and how changes to one affect others.
For ANZ mid-market teams, the CMDB makes several ITSM practices more effective. Incident management benefits when agents can see which CIs are affected by an outage. Change management benefits when assessors can see downstream dependencies before approving. Problem management benefits when analysts can trace recurring incidents to the CI that is the common factor. Without a CMDB, all of these rely on tribal knowledge. Which is incomplete, inconsistent and leaves with the people who hold it.
The Most Common Mistakes
Trying to capture everything. The single most common reason CMDB projects fail. Teams decide to build a complete picture of every device, application, network component, licence and cloud resource. Data collection takes months. By the time it is done, the early entries are already out of date. The maintenance burden overwhelms everyone and nobody sustains it.
The fix: scope your CMDB to the CIs needed to support your ITSM practices. Start with assets that appear most in incidents, changes and problems.
No data ownership model. A CMDB with no named owners for each CI class becomes inaccurate by default. If nobody is responsible for keeping laptop records current, laptop records will not be current. Assign ownership before go-live.
Manual-only data management. A CMDB maintained through manual updates alone will always be inaccurate. People forget to update records when a device is decommissioned, repurposed or moved. Discovery tools and integrations with procurement and HR systems automate the updates most commonly missed.
Building relationships before accuracy. CI relationships are the most valuable part of a mature CMDB. They are also the most complex to maintain and the quickest to become useless when underlying data is wrong. Build CI accuracy first. Add relationships once the foundation is solid.
Five Questions to Answer Before You Start
1. What Decisions Will the CMDB Support?
The most important question. Every CI class, attribute and relationship should exist because it supports a specific decision. Identify your top three use cases. Common answers for ANZ mid-market teams: impact assessment during major incidents, change risk assessment and asset lifecycle management.
Each use case determines what CI classes and attributes you need. Only build what your use cases require.
2. What CI Classes Will You Include?
A CI class is a category of configuration item: Laptop, Server, Application, Network Device, Business Service. For most ANZ mid-market teams implementing CMDB for the first time, four to six classes is the right starting scope.
| CI Class | What It Covers | Phase 1? |
|---|---|---|
| Hardware: End User | Laptops, desktops, monitors, mobile devices | Yes |
| Hardware: Infrastructure | Servers, storage, network devices, UPS | Yes |
| Software: Licensed | Applications with licence obligations | Yes |
| Business Service | IT services delivered to the business | Yes |
| Cloud Resource | AWS, Azure, GCP VMs and services | Phase 2 |
| Contract and Vendor | Support contracts, vendor SLAs | Phase 2 |
Four to six well-maintained CI classes is more valuable than fifteen where half the data is inaccurate.
3. What Attributes Does Each CI Class Need?
For each class, only capture attributes your use cases need. A practical attribute set for a Laptop CI: asset tag or serial number, make and model, OS and version, assigned user, department, purchase date, warranty expiry, end-of-life date, location, MDM status and current status. Eleven attributes. Every one supports a real decision.
4. How Will Data Stay Accurate?
Most CMDB projects answer this incorrectly or not at all. Manual-only updates become inaccurate within weeks of launch. The answer is automated discovery plus defined update triggers.
Automated discovery. Freshservice Discovery scans your network and populates hardware CI records including devices, software, specs and network config. It runs on a schedule and updates records automatically when changes are detected.
Defined update triggers. For attributes discovery cannot reach (business services, contracts, licences), define explicit triggers. When a new service goes live, create the CI. When a contract is renewed, update the expiry date. Embed these in your change management process so CI updates happen as a consequence of normal operations. Not as a separate task.
HR system integration. For the assigned user attribute on end-user hardware, integrate Freshservice with your HR system or directory. When an employee leaves or changes role, asset assignments update. Manual assignment updates are consistently the first thing to drift after launch.
5. Who Owns Each CI Class?
Assign a named data owner to each CI class before go-live. They are accountable for data quality. Not for updating every record personally. But for ensuring the update process works. Without named ownership, quality sits with nobody and the CMDB drifts.
For most ANZ mid-market teams: end-user hardware owned by the desktop team lead, infrastructure owned by the systems team lead, business services owned by the IT service manager, software licences owned by IT ops or procurement. Monthly data quality reviews are part of each owner’s role.
CMDB Setup in Freshservice: Configuration Steps
Step 1: Configure CI Classes and Attributes
In Freshservice: Admin, then Asset Management, then Asset Types. Freshservice includes default types: Laptop, Desktop, Server, Mobile, Software. Review these against your CI class model. Modify defaults to match your attribute requirements rather than building from scratch.
For each CI class, configure only the attributes your use cases need. A record with 10 fields every agent understands will be maintained. A record with 40 fields will not.
Step 2: Configure Discovery
Enable Freshservice Discovery in Admin, then Asset Management, then Discovery. Freshservice supports agent-based discovery, probe-based network scanning, and integrations via Azure AD, SCCM, Jamf and Intune.
For ANZ teams using Intune or Jamf, the Freshservice integration pulls device records directly from your MDM on a schedule. Device deployments, reassignments and decommissions reflect in Freshservice without manual work.
Set discovery to match your environment’s rate of change. Daily for dynamic environments. Weekly for more stable ones. Review the first run results. Are devices being classified correctly? Fix classification issues before full data population.
Step 3: Import Existing Asset Records
If you have existing asset data in a spreadsheet or previous platform, import it via CSV. Before importing, clean the source data. Remove decommissioned assets. Update ownership where staff have left. Standardise make and model naming so discovery records match imported records without creating duplicates. The import is the chance to start clean.
Step 4: Build CI Relationships
Start with the relationships your primary use cases need. If your Phase 1 use case is incident impact assessment, build infrastructure hardware to business service relationships first. These let an agent say “the server hosting our ERP has gone down — which services are affected?” with data rather than guesswork.
Do not try to build all relationships at once. Start with the 10 to 15 most critical. Add others as the CMDB matures.
Step 5: Link CMDB to Incident and Change Management
The CMDB delivers value when it is used in ITSM practices. Configure incident and change forms to include a CI association field.
For incidents: the CI field should be mandatory on major incidents. This links the incident to the affected infrastructure and feeds back into problem management when analysts look for recurring patterns.
For changes: the associated CI field identifies what is being changed. The CAB can see relationships during assessment and flag that a server change affects three business services.
Keeping Data Accurate Over Time
A CMDB accurate on day one that drifts to 60% within 12 months is worse than one never built. It creates false confidence in data that cannot be trusted.
Monthly data quality reviews. Each CI class owner reviews their records monthly. Devices without users. End-of-life dates passed without a decommission record. Applications with no associated server. This takes 30 to 60 minutes per owner per month and prevents the drift that makes CMDBs unusable.
Automated reconciliation. Configure Freshservice to flag discrepancies between discovered assets and CMDB records. Devices discovery finds that the CMDB does not have. CMDB records for devices not seen in 30 days. Queue these for human review rather than auto-resolving.
Embed updates in existing workflows. The most sustainable CMDB maintenance happens when CI updates are part of processes that already occur. New device deployed through procurement: CI created. Employee offboarding through HR: assets reassigned. Change implemented and closed: affected CIs updated. Maintenance embedded in normal operations is the only kind that survives beyond 12 months.
What KlickFlow Sees
A 290-person healthcare business in Melbourne came to us after their first CMDB was abandoned. The team had spent four months populating a comprehensive database covering every device, application, network component and cloud resource. By launch, data was already out of date. No discovery was configured. No ownership model existed. Six months later, nobody trusted it and nobody used it.
KlickFlow reset with a two-week design phase that answered the five questions above. Scope reduced to four CI classes: end-user hardware, infrastructure, business services and licensed software. Discovery configured via Intune for end-user devices and network scanning for infrastructure. Ownership assigned with monthly review commitments from three team leads. CI relationships built only for server-to-business service connections needed for incident impact assessment.
The new CMDB launched six weeks after the reset. Six months later, data accuracy was at 94% for end-user hardware. The change advisory board was using CI relationships in every major change assessment. The CMDB went from a failed comprehensive project to a working focused one. By doing less, more deliberately.
Frequently Asked Questions
How long does CMDB setup take?
A focused Phase 1 covering four to six CI classes with discovery configured takes four to eight weeks. Design phase (two weeks), configuration (one to two weeks), import and discovery setup (one to two weeks), testing and validation (one week). Teams that skip design and go straight to config take longer because they rebuild sections that do not fit their use cases.
Does Freshservice have built-in CMDB?
Yes. Native CMDB functionality is part of the IT Asset Management module, available from Growth plan upward. Includes asset type configuration, custom attributes, discovery via agent and probe, Intune, Jamf, Azure AD and SCCM integrations, CI relationship mapping and asset lifecycle management. Integrated directly with incident, problem and change management.
What is the difference between a CMDB and an asset register?
An asset register answers “what do we have?” A CMDB answers “what do we have, how does it connect, and what would be affected if it changed or failed?” For most ANZ mid-market teams, building an accurate asset register first and adding CMDB relationships in Phase 2 is the most practical sequence.
How many CI classes should we include?
Four to six in Phase 1. End-user hardware, infrastructure, business services and licensed software. Cloud resources, contracts and vendors are strong Phase 2 additions. A four-class CMDB at 95% accuracy is more valuable than a twelve-class CMDB at 60%.
What to Do Next
If you are planning a CMDB setup in Australia, start with a structured assessment before any configuration work begins.
Book a free CMDB assessment with KlickFlow. We will review your current asset management approach, identify the CI classes your ITSM use cases need and give you a practical CMDB design and implementation plan. No obligation.