The CMDB & Blast Radius page covers how to browse and read what's already in the CMDB. This page covers how it gets there in the first place, and how an admin keeps it accurate over time.
Adding or editing a CI
There's no single-CI "new item" form — CIs are added through Import JSON (a modal with a one-or-many CI array, plus a Validate step before you commit) or Import CSV (a column-mapping modal for spreadsheet uploads; relationships and custom attributes need Import JSON instead). Existing CIs are matched and updated by name, so re-importing the same name updates it rather than duplicating it.
CI lifecycle
A CI moves through planned → ordered → installed → in maintenance → retired → disposed (retired can go back to installed). The CI detail page only shows the buttons for whichever transitions are actually valid from its current status.
Managing relationships
From a CI's Relationships tab, pick another CI it depends on and a relationship type, then click Add. Outbound links you've added can be removed from this CI directly; an inbound link (something else depends on this CI) is removed from that other CI's own page instead.
CI classes
Settings → CMDB Admin → CI Classes defines the types of CIs your tenant tracks (Server, Network Device, and so on) and each class's attribute schema. Click + New Class to add one, or Edit/Delete an existing class.
Finding and merging duplicates
A background sweep flags likely-duplicate CIs in the same class — matched by IP, serial number, FQDN, or a close name match — and lists them under Settings → CMDB Admin → Duplicates with a reason and a match score. Click Keep on whichever CI should survive; the other is merged into it and retired, not deleted. You can also merge manually from any CI's own detail page via "Merge duplicate into this CI…".
CMDB Health
Settings → CMDB Admin → Health shows an overall trust score for your CMDB data, plus the share of CIs missing an owner, gone stale, or orphaned from the topology — with a 30-day history so you can see whether data quality is improving or slipping. Admins are notified automatically if the score drops below a healthy level.
Baselines
From a CI's Baselines tab, click Create Baseline to snapshot its current state. Later, diff any baseline against the CI's live state to see exactly what's drifted, field by field — useful for proving what changed since the last known-good configuration.
Automatic discovery
Beyond manual import, CIs can populate themselves. From CMDB → Discovery, set up:
- Network scanning — define IP ranges and ports to probe, on a manual, daily, or weekly schedule. Discovered hosts land in a review queue where you either Promote to CI (naming it and picking a class) or Ignore.
- Cloud discovery — connect an AWS, Azure, GCP, or Kubernetes account (credentials plus a schedule); PulseServe reads back your compute, database, storage, and cluster resources on a read-only basis and lists anything new in the same review queue for promotion.
Catching unauthorized changes
Settings → CMDB Admin → Compliance lists infrastructure changes that a discovery source (cloud or network scan) picked up with no covering Change record behind them — a sign something was modified outside your change-management process rather than through it. Review one, jump straight to the CI it affects, and click Resolve once you've looked into it (with an optional note on what you found). Switch between Open and Resolved to see what's still outstanding versus what's already been chased down.
Finding possibly-decommissioned CIs
Settings → CMDB Admin → Decommissioned lists CIs that cloud discovery used to see but no longer does — usually because the underlying resource was terminated outside of PulseServe. Open one to confirm it's genuinely gone, then retire it from its own detail page so the CMDB stops treating it as live.
Syncing with external tools
CI sync with an external ITSM tool is configured under Settings → Integrations, alongside sync for incidents, changes, problems, knowledge articles, and users — not a CMDB-only setting. See Integrations for the full setup.
Example
An admin connects an AWS account under CMDB → Discovery → Cloud Credentials. The next scheduled scan finds twelve EC2 instances and three RDS databases not yet in the CMDB. They show up in the review queue; the admin promotes the production ones to CIs, ignoring a handful of throwaway dev instances. A week later, the Duplicates panel flags one of those new CIs as a likely match for an existing hand-entered record with the same IP — the admin keeps the hand-entered one (it has a documented owner) and the duplicate merges into it.