Unblock standard changes with policy gates and governed runbooks

Autom Mate Platform
, , , ,
1

Scenario (from the Change Manager’s chair)

Last quarter we tightened change control after a few bad outages. Now we have the opposite problem: routine, low-risk “standard changes” (like restarting a stuck Windows service, clearing a print spooler, or rotating a non-prod app pool) are piling up because they still require the same human approvals and manual execution steps.

The service desk is stuck in a loop:

  • Incidents keep reopening (“it broke again”) because the fix never actually ran.
  • Engineers hesitate to run scripts directly (risk + audit).
  • CAB doesn’t want to review dozens of tiny changes.

ServiceNow (and ITIL change types) support standard/normal/emergency patterns, but in practice approvals can become a bottleneck if you don’t have clear policy gates and automation behind them. (servicenow.com)

What we want is governed execution: AI can recommend the right runbook, but Autom Mate is the deterministic execution + control layer that enforces policy, collects approvals, executes the steps, and logs everything.

Proposed end-to-end workflow (Autom Mate as execution layer)

1) Trigger

  • Trigger: ServiceNow Incident created or updated with a known pattern (e.g., “Print spooler stuck”, “IIS app pool recycle needed”, “Service restart required”).
  • Optional: An AI triage step suggests a runbook + confidence score, but AI does not execute.

2) Validation (context + policy checks)

Autom Mate pulls ticket context and evaluates deterministic gates:

  • Is the CI/service tagged as eligible for Standard Change automation?
  • Is the requester allowed to initiate this action?
  • Is this within an approved maintenance window?
  • Has this runbook been approved for this CI/environment?
  • Idempotency check: has this exact runbook already run for this incident/CI in the last X minutes?

3) Approval (human or rule-based)

  • If low-risk + pre-approved model: auto-approve (policy-based).
  • Otherwise: send an approval request to the right approver group.

Microsoft Teams approval prompt

  • Autom Mate posts an Adaptive Card to Teams with:
    • incident summary
    • proposed runbook
    • blast radius
    • rollback plan
    • Approve / Reject buttons

(Teams messaging + card interactions are supported patterns in Autom Mate’s Teams integration docs.)

4) Deterministic execution across systems

Once approved, Autom Mate executes the runbook steps in a controlled sequence:

  • Update ServiceNow ticket with “Approved – executing runbook”
  • Execute the technical action(s)
    • Integrations must be explicit:
      • If available: Autom Mate library connector for the target system
      • Otherwise: REST/HTTP/Webhook action to internal automation endpoints (e.g., an internal “runbook runner” API)
  • Post progress updates back to the incident

(Autom Mate is positioned as the orchestration layer that connects ITSM + messaging + backend systems and executes workflows end-to-end.)

5) Logging / audit

Autom Mate writes an audit trail:

  • who approved
  • what runbook version executed
  • inputs/outputs
  • timestamps
  • execution result
  • links back to the incident/change record

(Autom Mate emphasizes execution clarity and operational safety in recent releases, and is commonly used to improve auditability of automated operations.)

6) Exception handling / rollback

  • If execution fails:
    • automatically capture diagnostics
    • notify on-call in Teams
    • create/attach a Change record for break/fix if needed
    • run rollback steps if defined
    • keep the incident open and route to the right resolver group

Two mini examples

Mini example A: “Standard change” service restart that keeps getting delayed

  • Trigger: Incident “Payroll app slow” with known signature
  • Validation: CI is non-prod, low-risk, runbook is approved
  • Approval: auto-approved (policy)
  • Execution:
    • Update incident
    • Call internal runbook API via REST/HTTP/Webhook action to restart service + verify health endpoint
    • Post results to Teams + incident

Mini example B: Same runbook, but production + higher risk

  • Trigger: Incident “Customer portal errors”
  • Validation: CI is production, requires human approval
  • Approval: Teams Adaptive Card to Change Manager + App Owner
  • Execution:
    • Create a linked change record (or update an existing one)
    • Execute runbook with throttling + health checks
    • If health check fails, run rollback and escalate

Why governance matters (AI vs execution)

  • AI is great at suggesting the likely fix, but it’s probabilistic.
  • Direct AI action in IT systems can create:
    • unauthorized changes
    • inconsistent execution
    • weak audit trails
    • “who approved this?” gaps

Autom Mate sits between AI and systems as the policy + approval + deterministic execution layer, so you can safely operationalize AI recommendations without letting the model “click buttons in prod.”

Discussion questions

  • What do you consider “safe enough” to qualify as a standard change that can be auto-approved (by CI tag, risk score, time window, etc.)?
  • Where do you want approvals to live: inside ITSM only, or Teams-first approvals with ITSM as system-of-record?