Automating ServiceNow Tickets from Intune Non-Compliant Devices

#Operational requirement

The help desk currently raises a ServiceNow incident by hand every time someone notices a device sitting in the Intune “Non-compliant” bucket. That works at fifty devices. At five thousand it collapses: devices stay non-compliant for days, conditional access keeps blocking the user, and security only learns about a missed patch weeks later during an audit. As the newly hired systems administrator, you are closing that gap without building a bespoke monitoring agent. You will route Intune compliance telemetry into Azure Monitor, trigger a scheduled query alert on non-compliant device counts, and have that alert raise a ServiceNow incident automatically through the Table API. No human touches this pipeline once it is live.

Get it wrong and you get one of two failures. Either the alert never fires and devices stay silently non-compliant, or it fires on every polling cycle and floods the service desk with duplicate tickets until someone disables the integration out of frustration. Both outcomes damage trust in automation faster than the manual process ever did.

#Prerequisites and required permissions

• Intune Administrator or Global Administrator in Entra ID, enough to configure diagnostic settings under Tenant administration.
• An existing Log Analytics workspace, or Contributor rights to create one in the target subscription.
• Monitoring Contributor on the workspace and on the resource group hosting the Logic App.
• Logic App Contributor rights to build and publish the connector workflow.
• A ServiceNow integration account with incident_api web service access and credentials issued by your platform team.
• A change record raised before touching production alert rules or diagnostic settings — a botched rollout here generates noise the whole service desk sees.

#Step 1: Route Intune compliance telemetry to Log Analytics

Intune does not push compliance events anywhere by default; you must export them explicitly. In the Intune admin centre, go to Tenant administration > Diagnostic settings and create a setting named intune-compliance-to-loganalytics. Select the DeviceComplianceOrg category — it carries per-device compliance state changes, not just summary counts — and send it to your Log Analytics workspace.

Records typically appear in the IntuneDeviceComplianceOrg table sixty to ninety minutes after the first evaluation. This delay catches people out; do not assume the pipe is broken after twenty minutes of silence.

Capture a screenshot of the diagnostic setting and the workspace’s Resource ID for the change record. Confirm rows return before continuing:

1IntuneDeviceComplianceOrg
2| where TimeGenerated > ago(2h)
3| project TimeGenerated, DeviceId, UserId, ComplianceState
4| take 20

#Step 2: Build the scheduled query alert rule

In the workspace, go to Monitoring > Alerts > Create > Alert rule, scoped to the workspace. Use this KQL, which deduplicates by device so a device stuck non-compliant for six hours does not fire six times across six cycles:

1IntuneDeviceComplianceOrg
2| where TimeGenerated > ago(15m)
3| where ComplianceState == "Noncompliant"
4| summarize LatestEvent = arg_max(TimeGenerated, DeviceId, UserId) by DeviceId
5| project DeviceId, UserId, LatestEvent

Set evaluation frequency and lookback window to 15 minutes, threshold to “Number of results Greater than 0”, and set auto-resolve separately to 6 hours — otherwise you get flapping alerts as devices cross the compliance boundary during retries.

Export the rule as an ARM template and store it in your infrastructure-as-code repository, not just the portal. Confirm the rule shows Enabled and that a manual Preview evaluation returns the expected rows from Step 1.

#Step 3: Create the Action Group and Logic App shell

Create an Action Group in the same resource group named ag-intune-noncompliance-servicenow, with a single Logic App action. Build the Logic App with an HTTP request trigger; the common alert schema posts its JSON payload automatically once linked.

Add a Parse JSON action using the common alert schema as the sample payload, so later steps can reference alertContext, essentials.alertRule and essentials.firedDateTime cleanly. This matters because the raw payload structure changes if you ever move off the common schema, and unparsed field access then breaks silently.

Trigger the Logic App manually with a sample payload and confirm Parse JSON runs without a schema validation failure.

#Step 4: Call the ServiceNow Table API to raise the incident

Add an HTTP action after Parse JSON, targeting the ServiceNow incident table endpoint. Store the integration credentials in Azure Key Vault and reference them through a Key Vault connection — do not hardcode credentials into the HTTP action body, that is the fastest way to get this integration pulled during a security review.

1POST https://your-instance.service-now.com/api/now/table/incident
2Content-Type: application/json
3Authorization: Basic {base64 credentials from Key Vault}
4
5{
6 "short_description": "Intune device non-compliant: @{body('Parse_JSON')?['data']?['alertContext']?['condition']?['allOf'][0]?['metricValue']}",
7 "description": "Automated ticket raised from Azure Monitor scheduled query alert. Alert fired at @{body('Parse_JSON')?['data']?['essentials']?['firedDateTime']}. Review non-compliant device list before closing.",
8 "urgency": "2",
9 "impact": "2",
10 "category": "Endpoint Management",
11 "assignment_group": "Endpoint Operations",
12 "correlation_id": "intune-noncompliance-@{body('Parse_JSON')?['data']?['essentials']?['alertId']}"
13}

The correlation_id field is what keeps the queue from drowning. Configure a ServiceNow business rule on the incident table that rejects or auto-merges any submission whose correlation_id already has an open incident — without it, every 15-minute re-evaluation while a device remains non-compliant creates a fresh duplicate, because the alert rule’s auto-resolve window and ServiceNow’s state model know nothing of each other.

Capture the ServiceNow incident number returned in the response and a copy of the deduplication business rule script. Confirm a single incident appears with the correct short description and assignment group.

#Step 5: Wire it live and run a controlled test

Link the Action Group to the alert rule from Step 2. Then run a genuine test: take a lab device out of compliance deliberately — disable BitLocker on a pilot device enrolled in a policy requiring encryption — and wait through a full evaluation cycle, typically up to 8 hours by default unless shortened in the device configuration profile.

Capture timestamped screenshots showing the device going non-compliant in Intune, the matching row in IntuneDeviceComplianceOrg, the alert firing in Azure Monitor’s Alert history, and the resulting ServiceNow incident with matching correlation_id.

Before calling this production-ready, remediate the test device, confirm the alert auto-resolves within the 6-hour window, and confirm the ServiceNow incident does not auto-close on resolution — that decision belongs to the service desk workflow, not the automation.

#Verification

Retain the exported ARM template, the Logic App run history export for the successful test, the ServiceNow deduplication business rule script, and the KQL used in the alert logic, filed against the change record reference. An auditor or a colleague debugging a missed ticket needs to reconstruct exactly what fired and why without re-deriving it from the portal.

#Failure Modes

The most common failure is silence, not error. If the diagnostic setting points at the wrong workspace, or the DeviceComplianceOrg category is unticked, the alert rule evaluates against an empty table forever and never fires, with nothing visible anywhere. Always confirm the raw table query returns rows before trusting the alert.

A second trap is credential drift on the ServiceNow side. If the integration account’s password rotates under a corporate policy and nobody updates the Key Vault secret, the HTTP action returns an unauthorized response and the Logic App run shows Failed with no incident created — and nobody notices until the service desk asks why nothing has come through for a week. Set a Logic App run-failure alert of its own, routed to a channel your operations team actually watches.

Third, watch alert rule cost. Scheduled query rules on frequent evaluation windows against a noisy table can generate real Log Analytics query charges in large environments. On a tens-of-thousands device estate, consider widening the evaluation frequency to 30 minutes and adjusting the auto-resolve window to match.

Fourth, do not skip the correlation_id deduplication rule and assume the alert’s own auto-resolve logic prevents duplicate tickets. The alert rule and the ServiceNow incident lifecycle are two independent state machines. Nothing links them unless you build the link yourself.

#Rollback

If the pipeline needs to come out of production quickly — say, it is flooding the queue and the deduplication rule has a bug — work through these steps in order:

1. Disable the Action Group link on the alert rule, or toggle the rule to Disabled, in Azure Monitor > Alerts > Alert rules. This stops new firings immediately without deleting configuration.
2. In ServiceNow, bulk-update open incidents carrying the intune-noncompliance- correlation_id prefix to a holding state referencing the rollback change record, rather than closing them — the underlying compliance issues on those devices are still real.
3. Disable the Logic App trigger from its Overview blade, preventing queued or retried alert payloads from executing against the HTTP action while you fix the deduplication logic.
4. If the diagnostic setting itself is the source of unexpected data volume, remove it from Tenant administration > Diagnostic settings in Intune; existing rows remain in Log Analytics for investigation.
5. Re-enable in reverse order once fixed — diagnostic setting, alert rule, Logic App trigger, Action Group link — with a verification checkpoint before each next step.

Keep the diagnostic setting and alert rule templates version-controlled so rollback is a redeploy of a known-good state, not a manual reconstruction under pressure.

#Operational Summary

You have built a closed loop from Intune compliance evaluation through Log Analytics, an Azure Monitor scheduled query alert, and a Logic App that raises a deduplicated ServiceNow incident automatically. The deliverable is not just a working pipeline — it is the evidence trail: exported templates, run histories, and a tested rollback path that lets you pull this out of production without leaving orphaned tickets or silent gaps in compliance monitoring. Treat the correlation_id deduplication rule as the single most important control in this design; without it, automation meant to reduce noise becomes the thing generating it. Review Microsoft’s guidance on reviewing Intune logs using Azure Monitor and the Azure Monitor scheduled query alert rule documentation before adjusting evaluation frequency or thresholds in a live tenant.