Stop “fulfilled” M365 license tickets that don’t grant access

Problem: “License granted” tickets that don’t actually grant access

A very common service desk failure mode:

  • A user requests Microsoft 365 / Teams Phone / Project / Visio access via ITSM.
  • The ticket gets approved and marked fulfilled.
  • But the user still can’t use the app because:
    • Usage location wasn’t set (license assignment fails).
    • Group-based licensing has propagation delays.
    • A conflicting manual assignment / add-on SKU causes a partial assignment.
    • The request form didn’t capture the right SKU/service plan, so the fulfiller “guessed.”

This is exactly where AI can suggest what to do, but you still need a governed execution layer to:

  • validate prerequisites
  • apply the right license deterministically
  • prove what happened (audit)
  • handle retries/rollbacks safely

Autom Mate fits as the execution + control layer between ITSM/AI and Entra/M365, using deterministic actions, approvals, and full logging. Autom Mate supports API-based integrations (REST/SOAP) with centralized credential handling and logging, plus error handling with retries/notifications. oet → Entra license assignment → verification → audit

1) Trigger

  • Trigger: ServiceNow Service Catalog item (e.g., “Request Microsoft Project”) moves to Approved.
  • Trigger input: requester UPN, requested product, cost center, manager, requested duration (if time-bound).

Integration label:

  • ServiceNow → REST/HTTP/Webhook action (fallback)

2) Validation (context + policy checks)

Autom Mate validates before touching Entra:

  • Confirm requester identity exists in Entra (UPN lookup)
  • Check usageLocation is set; if missing, route to a “set usage location” sub-step
  • Check policy:
    • Is requester in an eligible department/cost center?
    • Is this SKU allowed for this role?
    • Is there an existing license that conflicts (or a bundle already covering it)?

Why this matters for AI governance:

  • An AI agent might infer “assign E5” from chat context, but license changes are high-impact (cost + security + service enablement). Autom Mate enforces deterministic rules before execution.

Integration label:

  • Microsoft Entra ID / M365 licensing endpoints → REST/HTTP/Webhook action (fallback)

3) Approval (human or rule-based)

  • If SKU is high-cost (e.g., E5, Teams Phone), Autom Mate posts an approval to Microsoft Teams:
    • Approver sees: user, SKU, justification, cost center, policy result, and “what will change.”
  • If low-risk (e.g., enable a service plan already included), allow rule-based auto-approval.

Integration label:

  • Microsoft Teams → Autom Mate library (supported messaging integrations are described as plug-and-play).

4) Deterministic execution across systems

Autom Mate eed sequence:

  • Set usage location (if required)
  • Assign license (group-based or direct assignment—your choice)
  • Wait/poll for assignment state until success or timeout
  • Write back to ServiceNow:
    • fulfillment notes
    • license assignment result
    • correlation IDs

Autom Mate’s API actions support standard HTTP methods and authentication patterns, and it logs API calls for monitoring and troubleshooting.

5) Logging / audit

  • Autom Mate stores:
    • who approved
    • what policy - what changed (before/after)
    • timestamps + correlation IDs

This is the “prove it” layer when Finance/SAM asks why a user got an expensive SKU.

6) Exception handling + rollback

If anything fails:

  • Use Autom Mate error handling to:
    • retry transient failures (e.g., propagation delays)
    • notify the service desk in Teams/email
    • create a follow-up task in ServiceNow with the exact failure reason

If partial assignment happened:

  • Roll back to the previous known-good state:
    • remove newly assigned SKU
    • restore prior group membership (if changed)
    • reopen the request with “needs manual review”

Autom Mate supports fallback actions, retries, and real-time notifications for failed tasks.


Two mini examples

Mini example A: “Teams Phone add-on didn’t apply”

  • Trigger: user requests Teams Phonealready has E3; Teams Phone requires additional add-on + correct usage location
  • Approval: telecom approver in Teams
  • Execution: set usage location → assign add-on → verify service plan enabled → update ServiceNow
  • Exception: if add-on assignment fails, Autom Mate retries and then opens a telecom task with the API error payload

Mini example B: “Project license request should be time-bound”

  • Trigger: contractor requests Project for 30 days
  • Validation: contractor type requires end date
  • Approval: manager approves in Teams
  • Execution: assign license + schedule an Autom Mate timer to auto-revoke on end date
  • Audit: ServiceNow updated with revoke schedule + approver

Discussion questions

  • Do you prefer group-based licensing (with propagation delays) or direct assignment (more immediate) for ITSM fulfillment—and how do you want Autom Mate to handle the verification window?
  • What’s your minimum governance bar: manager approval only, or manager + cost-center owner for high-cost SKUs?