Fix SharePoint orphaned permissions via governed ITSM runbooks

Autom Mate Platform
, , , ,
1

A weird pattern we hit in ops: a P1 incident gets opened because a VIP can’t access a critical SaaS app… but the real issue is that their Entra ID account is fine — it’s the SharePoint / M365 permission layer still referencing a deleted identity (or an old object) and the user is effectively “stuck” behind an orphaned permission entry.

This shows up as:

  • “User is in the right group, but still gets Access Denied”
  • “We removed the old account, re-hired the person, and now permissions are inconsistent”
  • “SharePoint still shows the old user in folder permissions even though Entra ID is clean” (essential.co.uk)

The service desk can triage it quickly, but execution is messy:

  • Fixing it often requires multiple systems (ITSM ticket, Entra ID checks, SharePoint permission cleanup, comms back to the user)
  • It’s risky to let an AI agent “just remove permissions” without guardrails
  • It’s easy to create a bigger outage by removing the wrong principal from the wrong site

What I want is a governed, deterministic workflow where AI can suggest, but Autom Mate is the execution + control layer that enforces policy, approvals, and audit.

Proposed governed workflow (Autom Mate as execution layer)

1) Trigger

  • Trigger: Incident created/updated in Freshservice with category “M365 / SharePoint Access” and keywords like “access denied”, “orphaned user”, “rehire”, “deleted account”.
    • Integration: REST/HTTP/Webhook action (Freshservice API) to fetch ticket details.

2) Validation (context + policy checks)

Autom Mate runs deterministic checks before any change:

  • Pull user identity context:
    • Query Entra ID for current user object, UPN, objectId, account status
    • Integration: REST/HTTP/Webhook action (Microsoft Graph)
  • Pull SharePoint site + item context:
    • Identify site URL/library/folder from ticket fields or a guided question back to the agent
    • Integration: REST/HTTP/Webhook action (SharePoint / Graph)
  • Detect “orphaned principal” indicators:
    • Permission entries referencing deleted users (still present in SharePoint’s user info list behavior) (essential.co.uk)
  • Enforce policy gates:
    • Only allow remediation if:
      • Ticket requester matches affected user (or is an approved delegate)
      • Target site is in an allowlist
      • Change scope is limited (single site/library/folder)

3) Approval (human-in-the-loop)

Because permission changes are high-risk:

  • If the workflow will remove/replace a principal, Autom Mate posts an approval request to Microsoft Teams:
    • “Approve cleanup of orphaned permission entry on Site X / Path Y for User Z?”
    • Integration: Autom Mate library (Teams) if available, otherwise REST/HTTP/Webhook action.
  • Approval rules:
    • Low-risk (single folder, non-sensitive site) → Site Owner approval
    • Higher-risk (site-wide, sensitive label, exec site) → Security/Collab Admin approval

4) Deterministic execution across systems

Once approved, Autom Mate executes a controlled runbook:

  • Snapshot current permissions (for rollback)
    • Store snapshot in Autom Mate storage / logs
  • Remove orphaned principal entry
  • Re-apply correct permissions to the current Entra identity (objectId-based)
  • Validate access:
    • Re-check effective permissions
    • Optional: ask user to retry and confirm

5) Logging / audit

  • Aut Inputs (ticket id, site, path)
    • Who approved
    • Exact actions executed
    • Before/after permission snapshot
    • Execution logs for troubleshooting and compliancg on-prem and need full control of log storage, Autom Mate supports logging architectures that can be backed by your own stack (e.g., Elasticsearch)

6) Exception handling / rollback

If anything fails mid-flight:

  • Autom Mate error handling:
    • Retry transient Graph/SharePoint calls
      -ll back to the permission snapshot
    • Notify the resolver group in Teams + update the Freshservice ticket with failure reason

Two mini examples

Mini example A: Rehire edge case

  • HR offboards user → Entra ID user deleted
  • User rehired → new Entra objectId
  • SharePoint folder still has permissions for the old identity reference
  • Autom Mate runbook:
    • Detect mismatch (old principal vs current objectId)
    • Approval → replace old principal with current identity
    • Validate access and close incident

Mini example B: “Access denied” after group fix

  • Service desk adds user to the right M365 group
  • User still blocked because a broken/orphaned explicit permission entry exists at folder level
  • Autom Mate runbook:
    • Snapshot folder ACL
    • Remove orphaned explicit entry
    • Re-apply intended group-based permission
    • Post confirmation back to ticket

Why governance matters (AI vs deterministic execution)

  • AI is great at recognizing the pattern (“this looks like an orphaned SharePoint user reference”), but it should not directly mutate permissions.
  • Autom Mate sits between AI and systems as the **execution - policy gates
    • approvals
    • deterministic runbooks
    • full audit trail of what actually changed

Questions

  • How are you currently detecting SharePoint/M365 “orphaned user” permission issues — only when users complain, or do you run proactive checks?
  • Would you require site-owner approval for every permission cleanup, or only when the scope exceeds a folder/library boundary?