Skip to main content

Service Management use case

IT operations workflow automation

IT operations workflows turn change requests, maintenance and routine operations tasks into processes that run the same way every time: the change record in ServiceNow, impact from the CMDB, the right approvals, the job run through your automation tools and a check in Datadog or Splunk afterward. Engineers keep their tools; the coordination between them is automated.

Works with ServiceNow change records, the CMDB, vSphere, AWS, Azure and Datadog or Splunk for verification.

How a change runs from request to verified

  1. Experience layer

    Request forms for changes and routine operations tasks, and an operator view showing each change, its approvals and its verification.

  2. Workflow layer

    A change request gathers impact from the CMDB, routes for approval by risk, waits for the maintenance window, runs the job through your automation tools, checks monitoring and closes or rolls back.

  3. Integration layer

    Creates and updates change records in ServiceNow, reads dependencies from the CMDB, triggers jobs in vSphere, AWS and Azure, and checks health in Datadog or Splunk afterward.

    • ServiceNow
    • Datadog
    • Splunk
    • VMware vSphere
    • AWS
    • Microsoft Azure

AI in IT and digital operations

AI summarizes changes for the CAB and alerts for the on-call engineer. Production and emergency changes are approved by people, and rollbacks wait for an engineer.

What AI does

  • Summarizes alerts and recent changes for the on-call engineer
  • Classifies incoming requests and suggests the owning team
  • Drafts change summaries for the change board

Decided by people, not by AI

  • Production changes
  • Emergency changes outside maintenance windows
  • Actions with customer impact

A routine change, five tools

Patching a production database cluster is routine, but it still involves a change record in ServiceNow, a list of dependent services from the CMDB, a CAB approval, a maintenance window, the job itself in Ansible or a vSphere snapshot followed by the patch, then someone watching Datadog afterward to make sure nothing broke. One engineer moves between five tools, and the change record is updated from memory the next morning.

Multiply that by every certificate renewal, firewall change and new application going into monitoring. IT operations spends much of its week coordinating work it already knows how to do.

The change as a workflow

  1. Request. An engineer fills in a change form: what, where, why and the proposed window. Kinetic creates the change record in ServiceNow.
  2. Impact. The workflow reads dependent services from the CMDB and lists them on the change, with their owners.
  3. Approval by risk. Standard changes on your pre-approved list go straight to scheduling. Normal changes go to the CAB with an AI-drafted summary. Emergency changes outside the window need the on-call manager.
  4. Implementation. At the start of the window, Kinetic takes the snapshot in vSphere or the cloud console, triggers the job in your automation tool and records the output.
  5. Verification. It checks the agreed monitors in Datadog or Splunk for a set period. If they stay healthy, the change closes. If not, the engineer is paged with the rollback step ready to approve.
  6. Record. The ServiceNow change is updated at each step, so the record is accurate when the change closes, not the next morning.

Other routine work

The same pattern covers new applications going live (monitoring set up, access groups created, CMDB entries added), certificate renewals ahead of expiry, and decommissioning. Each is a form, a workflow and calls to the tools that already do the technical work.

Kinetic doesn’t replace your automation scripts or your monitoring. It runs the process around them so they’re used the same way every time.

Infrastructure provisioning uses the same connections to vSphere and the cloud providers. When things go wrong rather than to plan, see incident response orchestration.

Questions about IT and digital operations

Answered by Kinetic Data. Last updated .

  • How is this different from our monitoring tool's automation?

    Monitoring and automation tools act inside their own scope: run a script, restart a service. Kinetic runs the process around them, including approvals, change records, notifications and follow-up tasks across teams, and calls those tools for the technical steps.

  • Does this replace change management in ServiceNow?

    No. The change record stays in ServiceNow, along with your CAB process. Kinetic fills in the record, routes approvals, runs the implementation steps and writes the results back.

  • Can standard changes run without a CAB?

    Yes, if your policy allows it. Changes you've pre-approved as standard, such as certificate renewals or routine patching, can run with no approver as long as they stay inside their window and pass verification.

  • Which automation tools can it trigger?

    Anything with an API, which covers Ansible, Terraform, vSphere, the cloud providers' APIs and most runbook tools. Kinetic records each job's output on the change.

Bring one process. Leave with a plan to build it.

Two hours with our team, at no cost. Bring one process that crosses your systems. We map it with you, show what Kinetic would build, and send you a written plan afterward.