Skip to main content

Auto-route identity tickets — ServiceNow workflow setup

This is the technical setup document for the canonical demo scenario in Auto-route identity tickets.

Do not use the older Azure OpenAI API-key triage flow as the demo narrative. The canonical production story is the live ServiceNow workflow that runs through Microsoft Graph and Microsoft Foundry under sn-ticket-router.

Canonical objects​

  • Workflow: Auto-route identity tickets
  • Identity / app: sn-ticket-router
  • Systems: ServiceNow, Microsoft Entra / Graph, Microsoft Foundry
  • Trigger object: incident

What the workflow does​

  1. A new identity-related incident or request is created in ServiceNow.
  2. Auto-route identity tickets triggers on that record.
  3. The workflow invokes the Graph - sn-ticket-router connection.
  4. The workflow runs as sn-ticket-router and queries Microsoft Graph for user and group context needed for routing.
  5. The workflow sends selected ticket and identity context to Microsoft Foundry for classification.
  6. The workflow writes the recommended route and priority back to the ServiceNow incident.

Authentication and authority model​

ServiceNow to Graph​

  • ServiceNow workflow uses connection: Graph - sn-ticket-router
  • Credential object: Azure Graph OAuth Client
  • Runtime identity: sn-ticket-router

Graph reach on the current path​

The current pull shows the sn-ticket-router identity with Microsoft Graph role bindings that grant:

  • Microsoft Graph: User.Read.All
  • Microsoft Graph: Group.Read.All
  • Microsoft Graph: Directory.Read.All

This is the core scope-drift story. The routing workflow is live, and the same identity now carries broader read reach than the narrow routing use case should require.

Microsoft Foundry step​

Microsoft Foundry is part of the same live execution path.

Use it as the model-classification hop for routing and prioritization, not as a separate scenario and not as a Logic App substitute.

Current graph objects to preserve​

The current graph pull already gives the right proof chain:

  • incident
  • Auto-route identity tickets
  • Graph - sn-ticket-router
  • Azure Graph OAuth Client
  • sn-ticket-router
  • Graph role and permission objects
  • stale owner signal on the router branch

For the demo, collapse noisy duplicates where possible and keep the click path centered on one executed chain.

Owner state​

The graph already shows the ownership problem on the router branch.

Treat this as no valid accountable owner, not as a generic metadata issue. The workflow still runs, but the owner record tied to the routing branch is stale, disabled, or otherwise not a current accountable human.

What changed vs baseline​

Frame only these changes:

  • Graph scope drift: the workflow now runs with broader Graph read reach than originally intended
  • ownership loss: the workflow and app no longer resolve to a valid accountable owner
  • Foundry added after baseline: model egress is now part of the executed path

Proof checklist​

To prove the end-to-end execution, show evidence from each system:

  • ServiceNow:
    • workflow execution for Auto-route identity tickets
    • triggering incident
    • write-back of route and priority to the incident
  • Entra / Graph:
    • sn-ticket-router identity
    • Graph role and permission bindings
    • Graph read activity for the same routing execution
  • Microsoft Foundry:
    • classification call on the same transaction
    • model step present on the post-baseline path

Do not make payload inspection part of the story. The proof is the execution, authority, reach, and structural drift on the path.

Demo constraint​

Keep the scenario to one path only:

  • one workflow
  • one runtime identity
  • one Graph branch
  • one Foundry step
  • one write-back to ServiceNow

If the graph shows extra internal objects, use them as supporting proof only after the main path is established.