Skip to main content

ITSM (ServiceNow)

Many customers use ServiceNow as the system of record for change requests while using Cloudaware CMDB for change visibility, impact analysis, and evidence.

Use this guide to review change management use cases. For setup details, see ServiceNow ITSM.

Common Patterns​

Cloudaware Detects Change → ServiceNow Change Request​

Use when you want high‑risk drift to always produce a formal ITSM record.

  • Trigger: CI field change meets entry criteria (prod tier, access/public exposure, large blast radius).
  • Action: create or update a ServiceNow change request with links to:
    • Impacted CI(s) in Cloudaware
    • CMDB relationship context (dependencies)
    • Recent change history for the service

Planned ServiceNow Change Request → Cloudaware Evidence​

Use when the lifecycle stays in ServiceNow but auditors/operators need CMDB‑backed evidence.

  • Link the ServiceNow change request to the primary CI(s) in Cloudaware.
  • Use the CI CHANGE MANAGEMENT tab to review:
    • Approval History (if Cloudaware approvals are used)
    • Changes History (what actually changed)

Two-Way State Synchronization (Where Applicable)​

Use when teams need consistent status across both systems.

  • ServiceNow status changes update Cloudaware tracking fields (or vice‑versa).
  • Closure can be automated when validation evidence is present (for example, no open violations, successful checks).
  • Assignment/routing: map to CMDB ownership (application, tier, owner/on‑call).
  • Risk: include risk band and blast radius summary in the change request.
  • Evidence: include links to Cloudaware dashboards and reports for audit packs.