Stop approved access tickets that never grant Entra group membership

Problem: “Approved” in ITSM, but the access never lands (and nobody notices)

A common identity-ops failure mode is:

  • A user requests access in ServiceNow (or another ITSM)
  • The request gets approved
  • The actual entitlement change in Microsoft Entra ID fails (missing group, dynamic rule conflict, Graph throttling, stale approver, etc.)
  • The ticket still gets marked Fulfilled (or sits in a weird limbo)

This is the classic ticket → action gap: the ITSM workflow records intent, but execution is best-effort and failures are easy to miss. This is especially painful when approvals are involved, because you can’t just “let AI fix it” directly in Entra without guardrails.

Microsoft’s own Entra entitlement flows include multi-stage approvals and escalation concepts, but they don’t solve the cross-system execution + audit problem when the request of record is in ITSM. (learn.microsoft.com)

Why AI alone is risky here

  • AI can suggest “add user to group X”, but it can’t be trusted to take direct action in identity systems without:
    • policy checks (is this group allowed for this user?)
    • deterministic execution (idempotent add/remove)
    • approvals (who authorized it?)
    • audit logs (what exactly changed, when, and by whom?)

Autom Mate’s role: the execution + control layer between AI/ITSM intent and real system changes.


End-to-end workflow (governed, deterministic)

1) Trigger

  • Trigger: ServiceNow Request Item (RITM) moves to “Approved” or a catalog item “Access Request” is submitted.
  • Autom Mate trigger: ServiceNow trigger (Autom Mate library).

2) Validation (context + policy checks)

Autom Mate enriches and validates before touching Entra:

  • Pull request details (requested user, requested role/group, business justification)
  • Pull user attributes from Entra (department, manager, employment type)
  • Check policy:
    • Is the requested group in an allowlist for this catalog item?
    • Is the requester allowed to request for someone else?
    • Is the target group “break-glass / privileged” and therefore requires extra approval?

Integrations

  • ServiceNow (Autom Mate library)
  • Microsoft Entra ID / Azure AD (Autom Mate library if available; otherwise REST/HTTP/Webhook action via Microsoft Graph)

3) Approval (human or rule-based)

  • If low-risk (e.g., standard app group): proceed with existing ServiceNow approval outcome.
  • If higher-risk (e.g., finance systems, admin roles): Autom Mate creates/updates an additional approval step:
    • Post an approval card in Microsoft Teams to - Or create a ServiceNow approval task

Integrations

  • Microsoft Teams (Autom Mate library)
  • ServiceNow (Autom Mate library)

4) Deterministic execution across systems

Autom Mate executes with idempotency and retries:

  • Compute an idempotency key: {ritm_number}:{user_object_id}:{group_id}:{action}
  • Execute “add member to group” (Graph)
  • Verify membership after write
  • If Graph throttles or transient failure:
    • retry with backoff
    • keep the ticket in “In Progress – Provisioning”

5) Logging / audit

Autom Mate writes an audit trail:

  • Store execution result (request payload, response, correlation IDs)
  • Update ServiceNow work notes with:
    • what was changed
    • who approved
    • timestamps

(Autom Mate supports API-basogging/monitoring of API calls, and secure auth handling like OAuth in Vault.)

6) Exception handling + rollback

If execution fails after partial completion:

  • If user was added to some groups but not all:
    • rollback by removing the user from groups added in this run
  • Create an Incident (or assign to Identity Ops queue) with full context
  • Notify in Teams with a “Retry” button that replays the run using the same idempotency key

Two mini examples

Mini example A: “Approved” but group doesn’t exist anymore

  • ServiceNow catalog item still references APP-FIN-READERS
  • Group was renamed/deleted in Entra
  • Autom Mate validation step detects missing group and:
    • blocks execution
    • routes to app owner for remediation
    • prevents a false “Fulfilled” outcome

Mini example B: Entra request succeeds, but ServiceNow update fails

  • Graph add-member succeeds
  • ServiceNow API update fails (network / auth)
  • Autom Mate:
    • retries ServiceNow update
    • if still failing, posts to Teams and opens a follow-up task
    • keeps the run state so it doesn’t re-add the user (idempotent)

Implementation notes (what to build in Autom Mate)

  • Flow inputs: RITM number, requested_for, entitlement identifier, risk tier
  • Policy table: allowlisted entitlements per catalog item + required approver group
  • Execution: Graph calls via REST/HTTP/Webhook action if Entra connector isn’t available
  • Controls:
    • timeouts + retries
    • idempotency keys
    • explicit “verify” step after each change

Autom Mate is designed to connect ITSM + collaboration channels and execute end-to-end workflowgn stopping at “AI suggested a fix.”


Discussion questions

  • Where do you see the biggest failure rate today: approval routing, execution in Entra, or ticket state drift?
  • Would you prefer the “Retry / Rollback” controls to live in Teams, ServiceNow, or both?