The Intune SOC Triage Console replaces manual portal navigation for device compliance triage. It combines device health, compliance policy states, app deployment status, and active alerts into a single always-on interface. Engineers can search, filter, sort, and drill into any device to view policy failures and trigger remote remediation actions without leaving the console.

The console uses four tabs: Devices (main triage list with detail panel), Alerts (critical and warning alert feed), Compliance (policy-level rollup with 6-month trend chart), and Apps (deployment status with per-app device breakdown). An AI Summary button in the device detail panel sends device context to Claude Sonnet for an automated SOC triage write-up.

Selecting one or more checkboxes shows the bulk toolbar with three actions that require confirmation: Sync All (syncDevice), Reboot All (rebootNow), and Collect Diag (collectDiagnostics). A confirm modal shows device names before executing. In live mode, each selected device would receive a separate POST request.

The Export button opens a dropdown with CSV and JSON options. Exports the currently visible (filtered) device list. Fields exported: name, user, OS, version, model, serial, compliance, lastSync, risk, alerts, encrypted, firewall, AV, patches, enrolled. No API call required — purely client-side from allDevices in memory.

Shows a policy compliance table from DEVICE_POLICIES[d.id] (or falls back to derived fields). Labeled with the corrected Graph endpoint: GET /managedDevices/{id}/deviceCompliancePolicyStates. In live mode this should be fetched per-device on detail expand.

Lists apps installed on the selected device from DEVICE_APPS[d.id]. Labeled with GET /deviceAppManagement/mobileApps?deviceId={id}. The correct live endpoint to achieve this is GET /v1.0/deviceAppManagement/mobileApps/{appId}/deviceStatuses filtered by device ID — there is no single Graph call that returns all apps for one device directly.

Auto-generates a plain-text triage ticket note from device fields and policy failures. Includes the correct Graph API calls used. A Tech Notes textarea auto-saves to localStorage keyed by device ID with a 600ms debounce. Copy Full Ticket combines the ticket and notes to clipboard.

Graph API calls require a Bearer token issued by Entra ID (Azure AD). The recommended approach for this browser-based console is MSAL.js with PKCE flow. The Sign-In modal shows the required setup details.

The graphFetch(endpoint) function is the single fetch entry point for all Graph calls. The production block (commented out) calls acquireMSALToken() and passes the Bearer token. Uncomment this block and comment out the mock fallback to go live.

• Register a new application in the Entra ID portal (App registrations → New registration)
• Set platform: Single-page application (SPA) — add the serving origin as redirect URI
• Add delegated API permissions: DeviceManagementManagedDevices.Read.All (minimum)
• Add DeviceManagementManagedDevices.ReadWrite.All if remote actions are needed
• Add DeviceManagementApps.Read.All for app catalog
• Grant admin consent for the organization on all added permissions
• Note the Application (client) ID and Directory (tenant) ID for MSAL config

• Add MSAL.js CDN script tag to the file head: <script src="https://alcdn.msauth.net/browser/3.x.x/js/msal-browser.min.js"></script>
• Implement acquireMSALToken() using PublicClientApplication with acquireTokenSilent → acquireTokenPopup fallback
• Fill in clientId and authority in the MSAL config object
• Wire the real Sign-In button to call msalInstance.loginPopup()

• Open stack-intune-triage.html and locate the DEMO constant near the top of the script block
• Set const DEMO = false;
• In graphFetch(), uncomment the 8-line production block (fetch with Bearer token)
• Comment out (or delete) the mock return new Promise(resolve => setTimeout(...)) fallback block
• Reload — Sign In prompt should appear; authenticate with a user who has Intune read access
• Verify device list populates with real device names (not CORP-WIN-JSMITH01)
• Verify gauge counts match the Intune portal total device count
• Test sync action on a non-critical test device; confirm 204 response in the action modal log
• Verify AI Summary works (Anthropic API key available in browser environment)

Cause: renderGauges() was called before allDevices was populated, or the loading modal was dismissed before closeModal() ran loadDashboard().

Fix: Check browser console for JS errors. In demo mode this should not occur. Confirm closeModal() calls loadDashboard() and that allDevices = [...DEVICES] runs before loadDashboard(). If the modal close button is clicked before the animation completes, runLoadingSequence interval may still be running — verify clearInterval is called on close.

Cause: An active gauge filter combined with search text returns no matches.

Fix: Click Show All in the list header or press the filter chip ×. Check if a gauge filter is active (highlighted border). Call clearAllFilters() from the console to reset everything. In live mode, confirm graphFetch('/v1.0/deviceManagement/managedDevices') returns a non-empty value array.

Cause: selectDevice(id) called DEVICES.find(x => x.id === id) but the ID did not match (possible if allDevices was replaced with a different object reference).

Fix: Confirm allDevices is always initialized to [...DEVICES]. Check that row data-id attributes match the d.id values in the DEVICES constant. In live mode, ensure the device IDs returned by Graph API are stored directly as d.id in the normalized device objects.

Cause: runRemoteAction(action, deviceName) called with an action key not in the steps object; falls through to the default branch which should still work. Or the action modal element is missing from the DOM.

Fix: Check browser console for errors. Verify document.getElementById('actionModal') returns the element. Confirm the action key is one of: sync, wipe, reboot, retire, lock, bitlocker, collect, reset. All are now explicitly defined in the steps object after the audit fix — none fall to the generic default anymore.

Cause: The fetch call to https://api.anthropic.com/v1/messages failed. Common reasons: no network access to Anthropic from the current environment, CORS policy rejection, or the Anthropic API key is not configured (the code currently does not send an API key — this requires proxy-side key injection).

Fix: Route AI calls through a server-side proxy that injects the x-api-key header. The offline fallback (buildOfflineSummary()) is fully functional and accurate — it reads the same device fields and produces a useful triage summary without any network call. Consider this sufficient for demo environments.

Cause: startAutoRefresh(30000) was not called, or the intervals were cleared without being restarted.

Fix: Check _refreshInterval and _countdownInterval are non-null after boot (log them from the console). Confirm the BOOT section at the bottom of the script calls startAutoRefresh(30000). Manually call refreshAll() from the console to confirm the data cycle works independently of the timer.

Cause: MSAL token is expired, not acquired, or the scope does not match the endpoint.

Fix: Verify the token is acquired before the graphFetch() call. Check that the Entra ID app registration has admin consent granted for all required scopes. Test the token manually: curl -H "Authorization: Bearer {token}" https://graph.microsoft.com/v1.0/me. For remote actions (POST endpoints), confirm the ReadWrite.All scope is present — Read.All alone will return 403 on action endpoints.

Cause: Chart.js CDN script failed to load, or destroyChart() was not called before re-initializing a chart on the same canvas element.

Fix: Check browser console for Chart is not defined error. Verify the CDN URL is accessible from the deployment environment (cdnjs.cloudflare.com). If deploying in an air-gapped environment, bundle Chart.js locally. The activeCharts object and destroyChart() function prevent canvas reuse errors — confirm they are both present and called before every chart initialization.