Skip to main content

Change Management Overview

The Cloudaware platform uses Force.com capabilities such as flows (workflow rules) and approval processes for change tracking and reporting. Change Management connects configuration changes detected in the CMDB with approvals, notifications, automation, ITSM workflows, and audit evidence. It helps IT and security teams reduce operational risk while maintaining delivery velocity across multi‑cloud and hybrid environments.

info
  • Audience: Cloud and platform teams, SRE teams, security and compliance owners, ITSM administrators
  • Outcome: CMDB‑linked change governance with approvals, automation, and audit‑ready evidence for planned and detected changes

Use this documentation section when you want to:

  • Track configuration changes on CIs (who changed what and when) using CMDB history.
  • Route high‑risk changes for approval (CAB or targeted approvers) and keep evidence for audits.
  • Standardize low‑risk work via templates and playbooks (standard changes) to reduce toil.
  • Integrate with ITSM (for example, ServiceNow) and collaboration tools for notifications and ticketing.
  • Apply policy controls to prevent or slow down non‑conforming changes before they reach production.

How Change Management Works​

Change Management in Cloudaware is built on top of Cloudaware CMDB: When a configuration item (CI) changes, Cloudaware can record the change in CMDB history and display it in the CI’s CHANGE MANAGEMENT tab. Where approval or automation workflows are configured, the change can also be routed to approvers, external systems, and downstream actions.

Its CMDB-first model provides:

  • Change visibility: CMDB history records changes detected through cloud integrations, external systems, and where relevant, agent telemetry.
  • Operational context: CI ownership, environment, account, application, and service information can be used to evaluate and route changes.
  • Impact analysis: CI relationships and Cloudaware Virtual Applications help identify related infrastructure and services.
  • Governance: Approval decisions, timestamps, notifications, and change evidence can remain associated with the affected CMDB records.
  • Automation: Flows can notify teams, create or update external tickets, and initiate configured follow-up actions in systems like Slack, ServiceNow, Jira, PagerDuty, etc.

High-Level Setup Flow​

  1. Populate Cloudaware CMDB. Connect the required cloud providers, platforms, and data sources through Cloudaware integrations.
  2. Identify governed CIs and fields. Decide which CI classes, fields, environments, and applications require change tracking or approval controls.
  3. Enable history tracking. Configure history for the fields required for operational review and audit evidence. See History & Audit.
  4. Define approval policies. Identify high-risk change patterns, approvers, routing criteria, and escalation paths. See Approvals.
  5. Configure notifications. Route change information to the appropriate teams and systems. Notifications and ITSM (ServiceNow).
  6. Define reporting and evidence requirements. Specify which change, approval, ownership, and validation information must be retained.
  7. Standardize recurring workflows. Document repeatable procedures and automate appropriate low-risk changes.

Change Events vs. Change Requests​

Cloudaware supports both detected change events and planned change requests. Organizations commonly use them together.

  • Change events (detected): A detected change event occurs when Cloudaware identifies a change to a CI field and records it in CMDB history. Use detected changes to:

    • Identify configuration drift.
    • Review before-and-after field values where history tracking is enabled.
    • Detect changes that occurred outside an approved process.
    • Trigger notifications or automation for selected change patterns.
    • Preserve evidence for investigations and audits.

  • Change requests (planned): a human‑driven request that moves through a lifecycle (proposed → scheduled → implemented → verified). Planned requests may be managed in an ITSM platform such as [ServiceNow] and linked to:

    • Affected CIs.
    • Applications or services.
    • Owners and implementation teams.
    • Approval records.
    • Implementation and validation evidence.
    • Changes subsequently detected in Cloudaware.

Change Events in Cloudaware UI​

On many CI detail pages, the CHANGE MANAGEMENT tab provides two audit‑style panels:

  • Approval History: when approvals are used, this shows who approved/rejected and when.
  • Changes History: a time‑scoped log of changes to the CI.

For details on the tab layout, see CI Detail Page Layout and History & Audit.

Reading Path​

Use these guides together as the Cloudaware Change Management documentation set.

  • Requirements: prerequisites for CMDB data, ownership context, history tracking, integrations, permissions, and change governance.
  • Integrations: ServiceNow change request patterns, notification routing, collaboration channels, and downstream workflow connections.
  • Reporting & Approvals: approval rules, routing logic, escalation paths, audit reports, and evidence pack structure.
  • FAQ: common questions about Cloudaware Change Management.