.png)
Microsoft Intune Integration Guide
Microsoft Intune integrates with enterprise systems primarily through Microsoft Graph REST APIs, Microsoft Entra ID authentication, resource-specific change notifications, and scheduled workflows.
Microsoft Intune integration options at a glance
Microsoft Intune exposes its primary management interface through Microsoft Graph REST APIs over HTTPS and JSON. Authorized integrations can read and manage managed devices, compliance policies, configurations, applications, detected applications, and Windows Autopilot device identities. Microsoft Graph uses Microsoft Entra ID OAuth 2.0 with delegated permissions or application roles. Resource-specific change notifications may support selected event-driven scenarios, while scheduled polling is required when notification coverage is unavailable. JSON batching supports grouped requests, and specialized application-content APIs support staged uploads. Martini can orchestrate these interactions, paginate and transform Graph responses, apply business rules, and expose normalized APIs to downstream systems.
| Integration point | Supported by Microsoft Intune? | Common use cases | How Martini supports it |
|---|---|---|---|
| Microsoft Graph REST APIs | Yes | Read, create, update, and delete Intune resources; retrieve device inventory and compliance state; assign applications and policies; and initiate supported device actions. | Martini can consume Microsoft Graph REST endpoints, manage request configuration, transform JSON, orchestrate multi-step workflows, and expose normalized APIs. |
| Authentication | Yes | Microsoft Graph uses Microsoft Entra ID OAuth 2.0 with delegated permissions for interactive applications and application roles for services, scheduled jobs, and daemon integrations. | Martini can securely configure OAuth-based API access and store client credentials and related configuration using secrets-management facilities. |
| Webhooks / outbound callbacks | Limited | Microsoft Graph change notifications support selected resources and events, but Intune does not provide a universal event stream for all device, policy, compliance, or application changes. | Martini can receive supported webhook notifications and use scheduled workflows with polling, filtering, and state tracking when the required resource is not covered. |
| JSON batching | Yes | Microsoft Graph JSON batching can group multiple HTTP requests, subject to Graph batch limits, operation behavior, and independent throttling. | Martini can construct and process batched API calls within workflows while handling individual response failures and retry decisions. |
| Asynchronous operations | Yes | Some application-content workflows and device-management actions may return an accepted request or operation status that must be monitored separately. | Martini can retain correlation data, poll operation status where required, apply timeouts, and distinguish accepted work from completed work. |
| File / application content APIs | Limited | Intune application management supports specialized content and content-file resources, including staged or chunked application-content processing. | Martini can orchestrate the application-specific upload sequence and transform metadata, but this is not a general-purpose file repository integration. |
| Scheduled synchronization | Yes | Scheduled polling is appropriate for resources without suitable change notifications and for reconciliation of device, compliance, application, or policy state. | Martini scheduler-triggered workflows can paginate through Graph collections, persist checkpoints, upsert targets, and retry interrupted work. |
| Database / direct analytics access | No | Microsoft Intune does not expose a customer-facing relational database for direct integration. Reporting and export facilities may be more suitable for reporting workloads. | Martini can consume Graph reporting or export interfaces when available, but it does not require or assume direct database access to Intune. |
How Microsoft Intune exposes data and business events
Microsoft Intune REST APIs
Microsoft Intune's primary programmatic interface is Microsoft Graph REST. It exposes device management, compliance, configuration, application management, Autopilot, and supported device-action resources using HTTPS and JSON.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates to Microsoft Graph with Microsoft Entra ID, calls the required Intune resource, follows pagination, maps the response into a canonical model, applies business rules, and writes to or exposes the resulting data.
Implementation sequence
Microsoft Graph Change Notifications
Microsoft Graph supports change notifications for selected resources and events. Coverage is resource-specific, so Intune integrations must verify whether the required device, policy, compliance, or application resource supports subscriptions.
Martini implementation pattern
Martini implementation pattern: expose or configure a workflow endpoint for supported notifications, validate the notification, retrieve the current Graph resource rather than relying only on the event payload, and use scheduled polling for resources without sufficient notification coverage.
Implementation sequence
Scheduled Microsoft Intune Synchronization
Scheduled polling is the dependable fallback when change notifications are unavailable or incomplete. Graph collection responses commonly use @odata.nextLink, and incremental retrieval depends on the capabilities of each resource.
Martini implementation pattern
Martini implementation pattern: trigger a workflow on a schedule, read the saved cursor or timestamp, retrieve filtered and paginated resources where supported, upsert changes, and persist a checkpoint only after successful processing.
Implementation sequence
Microsoft Graph JSON Batching
Microsoft Graph JSON batching allows multiple requests to be submitted in one HTTP request, subject to Graph limits and the behavior of each individual operation. Batch responses still require per-request evaluation.
Martini implementation pattern
Martini implementation pattern: assemble independent Graph requests, submit a batch, inspect each response separately, retry eligible failures according to throttling guidance, and preserve dependency or ordering requirements for operations that cannot run independently.
Implementation sequence
Intune Application Content APIs
Intune application management includes specialized application-content and content-file resources. Upload and processing flows may be staged or chunked and are distinct from general-purpose attachment handling.
Martini implementation pattern
Martini implementation pattern: validate the application package and metadata, orchestrate the documented content sequence, monitor processing status where required, and update the approval or deployment process only after the operation reaches the intended state.
Implementation sequence
Common Microsoft Intune integration patterns
Pattern 1: Synchronize Intune devices to ServiceNow
When to use this pattern
Use this pattern when service management or asset teams need current endpoint inventory, ownership, operating system, enrollment, and compliance information. Scheduled synchronization is appropriate when notification coverage is insufficient.
Integration direction
Example Mapping
| Microsoft Intune Field | Canonical Field | Target Field |
|---|---|---|
| managedDevice.id | device.externalId | ServiceNow Configuration Item external ID |
| managedDevice.deviceName | device.name | ServiceNow Configuration Item name |
| managedDevice.operatingSystem | device.operatingSystem | ServiceNow operating system |
| managedDevice.complianceState | device.complianceState | ServiceNow compliance status |
Martini implementation pattern
A scheduled Martini workflow retrieves managedDevice pages, follows @odata.nextLink, maps Graph JSON into a canonical device model, and upserts ServiceNow records by stable identifiers. It stores a checkpoint, handles 429 responses using Retry-After and bounded backoff, and routes malformed records to an error workflow without duplicating existing items.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Create compliance work items from Intune state
When to use this pattern
Use this pattern when noncompliant devices should generate or resolve operational work in ServiceNow or Jira Service Management. It prevents repeated polling from creating duplicate incidents or tasks.
Integration direction
Example Mapping
| Microsoft Intune Field | Canonical Field | Target Field |
|---|---|---|
| managedDevice.id | compliance.deviceId | ServiceNow Configuration Item reference |
| managedDevice.complianceState | compliance.status | ServiceNow incident priority and state |
| managedDevice.userPrincipalName | compliance.owner | ServiceNow caller or affected user |
| managedDevice.lastSyncDateTime | compliance.observedAt | ServiceNow work item correlation field |
Martini implementation pattern
Martini polls eligible device and compliance data, applies thresholds and exception rules, then creates, updates, or resolves downstream work using the Graph device ID as a deduplication key. The workflow records the observed state and correlation ID so repeated polls remain idempotent.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- business rules
- idempotent upserts
- error handling
Pattern 3: Orchestrate application or policy assignments
When to use this pattern
Use this pattern when an approval portal or business process must assign an Intune application, configuration profile, or compliance policy to a Microsoft Entra group.
Integration direction
Example Mapping
| Microsoft Intune Field | Canonical Field | Target Field |
|---|---|---|
| request.applicationId | assignment.resourceId | Microsoft Graph mobileApp id |
| request.groupId | assignment.targetGroupId | Microsoft Entra group assignment target |
| request.approver | assignment.approvedBy | Martini audit record |
| request.operation | assignment.action | Microsoft Graph assignment operation |
Martini implementation pattern
A Martini API accepts the approved request, validates the application or policy and target group, checks authorization and duplicate assignment conditions, and calls Microsoft Graph. If the operation is asynchronous, the workflow polls status and reports accepted, completed, or failed outcomes separately.
Martini capabilities used
- Martini APIs
- workflow orchestration
- OAuth 2.0 API consumption
- validation
- business rules
- asynchronous status handling
- audit logging
Pattern 4: Register Windows Autopilot devices
When to use this pattern
Use this pattern when procurement or endpoint lifecycle systems submit device identifiers for Windows Autopilot registration and need a reliable processing result.
Integration direction
Example Mapping
| Microsoft Intune Field | Canonical Field | Target Field |
|---|---|---|
| device.serialNumber | autopilot.serialNumber | windowsAutopilotDeviceIdentity serialNumber |
| device.hardwareIdentifier | autopilot.hardwareIdentifier | Windows Autopilot hardware identifier |
| device.groupTag | autopilot.groupTag | Windows Autopilot groupTag |
| device.assignmentProfile | autopilot.profileReference | Provisioning profile association |
Martini implementation pattern
Martini validates required identifiers and tenant-specific rules, checks for duplicate identities, submits the resource through Microsoft Graph, and reconciles the resulting registration status. Validation failures are returned to the source system, while transient Graph failures are retried with correlation and bounded concurrency.
Martini capabilities used
- Martini APIs
- workflow orchestration
- data validation
- data mapping
- business rules
- retry handling
- status reconciliation
Applications commonly integrated with Microsoft Intune
Microsoft Intune commonly participates in Microsoft endpoint, security, service management, and provisioning architectures. Martini can coordinate these systems through Microsoft Graph and the relevant APIs of adjacent applications, without requiring a dedicated Intune connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Microsoft Entra ID | Intune uses Microsoft Entra ID for tenant identity, groups, application registration, and authorization. Group and user information can be used to resolve policy and application assignments. | Microsoft Entra ID → Martini → Microsoft Intune | Martini retrieves authorized users or groups, validates assignment requests, calls Microsoft Graph for Intune policy or application operations, and records correlation and result data. |
| Microsoft Defender for Endpoint | Endpoint security workflows can correlate Defender device risk with Intune compliance state and initiate approved remediation actions. | Microsoft Defender for Endpoint → Martini → Microsoft Intune | A Martini workflow retrieves security or device state from the relevant Microsoft APIs, applies remediation rules, and invokes supported Intune device or policy actions with audit logging. |
| Microsoft Sentinel | Security operations teams can use endpoint and compliance information in incident investigation and response workflows. | Microsoft Intune → Martini → Microsoft Sentinel | Martini polls or receives eligible security-related data, maps device and compliance context into Sentinel-facing events or work items, and preserves tenant and device correlation identifiers. |
| ServiceNow | Organizations can synchronize managed devices, ownership, compliance issues, and lifecycle information with service management and configuration processes. | Microsoft Intune → Martini → ServiceNow | A scheduled Martini workflow retrieves paginated managedDevice and compliance data, upserts ServiceNow records, deduplicates incidents, and routes approved remediation requests back through Microsoft Graph. |
| Jira Service Management | Endpoint incidents, access requests, and remediation tasks can be created or updated from Intune device and compliance state. | Microsoft Intune → Martini → Jira Service Management | Martini applies compliance rules to Graph responses, creates or updates Jira work items using stable device identifiers, and processes approved actions through a controlled workflow. |
| Microsoft Configuration Manager | Co-managed environments may coordinate device administration between Configuration Manager and Intune. | Microsoft Configuration Manager → Martini → Microsoft Intune | Martini reconciles device or management-state data from the available Microsoft interfaces, applies ownership and scope rules, and reports mismatches for operational follow-up. |
How to build a Microsoft Intune integration in Martini
Objective
Establish Microsoft Graph access using Microsoft Entra ID OAuth 2.0 and the least-privileged permissions required for the selected Intune resources and operations.
Instructions in Martini
- Create or select the Microsoft Entra application registration.
- Choose delegated permissions or application roles according to the integration runtime.
- Request administrative consent where required.
- Store tenant identifiers, client configuration, and secrets using Martini secrets management.
Objective
Select an event-driven or scheduled initiation strategy based on the Microsoft Graph resource's actual change-notification coverage.
Instructions in Martini
- Verify whether the required Intune resource supports Microsoft Graph change notifications.
- Use a Martini API or webhook workflow for supported notifications.
- Use the Martini scheduler for polling and reconciliation where notifications are unavailable or incomplete.
- Define the synchronization interval and checkpoint strategy.
Objective
Read the relevant Microsoft Graph Intune resources while respecting pagination, filtering support, throttling, and tenant scope.
Instructions in Martini
- Call the appropriate deviceManagement or deviceAppManagement resource.
- Follow @odata.nextLink until the collection is complete.
- Use $select and supported filters to reduce unnecessary data transfer.
- Handle HTTP 429 responses and honor Retry-After when provided.
Objective
Coordinate resource retrieval, enrichment, target writes, asynchronous status checks, and failure paths in a maintainable Martini workflow.
Instructions in Martini
- Separate retrieval, transformation, business rules, and target writes into clear workflow stages.
- Use JSON batching only for suitable independent requests.
- Poll operation status when an Intune action is asynchronous.
- Persist correlation IDs and checkpoints at safe transaction boundaries.
Objective
Convert Microsoft Graph JSON and OData response structures into the canonical and target schemas required by downstream systems.
Instructions in Martini
- Map actual Intune objects such as managedDevice, mobileApp, and windowsAutopilotDeviceIdentity.
- Normalize dates, ownership, compliance values, identifiers, and status fields.
- Preserve source IDs and tenant context for traceability.
- Validate required fields before issuing target writes.
Objective
Apply authorization, scope, deduplication, compliance, assignment, and lifecycle rules before changing Intune or downstream systems.
Instructions in Martini
- Use stable Graph IDs and device identifiers as idempotency keys.
- Protect remote device actions and policy changes with explicit approval rules.
- Distinguish legacy deviceConfigurations from newer configurationPolicies.
- Prevent duplicate incidents, assignments, and Autopilot identities.
Common Microsoft Intune data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| managedDevice | Synchronize endpoint identity, operating system, ownership, enrollment, compliance, management status, serial number, and last-contact information. | ServiceNow, Jira Service Management, Microsoft Sentinel, asset platforms | Martini retrieves paginated resources, uses Graph IDs and stable device identifiers as keys, maps fields into target schemas, and performs idempotent upserts. |
| deviceCompliancePolicy | Represent compliance requirements and support policy inventory, auditing, and governance workflows. | ServiceNow, reporting platforms, governance repositories | Martini reads policy definitions and assignments, normalizes policy metadata, and correlates policy state with managedDevice results. |
| deviceConfiguration | Represent device configuration profiles and their deployed settings. | Configuration repositories, governance platforms, service management systems | Martini retrieves configuration resources, distinguishes legacy configuration models from newer policy models, and maps settings for comparison or reporting. |
| mobileApp | Represent applications managed or deployed through Intune, including application metadata and assignment-related information. | Approval portals, procurement systems, service management platforms | Martini validates application requests, maps metadata, orchestrates Graph create or update operations, and tracks asynchronous processing where applicable. |
| detectedApp | Provide application inventory detected on managed devices for compliance, licensing, and security analysis. | ServiceNow, Microsoft Sentinel, asset and reporting platforms | Martini performs scheduled retrieval, pagination, filtering where supported, and deduplicated synchronization using Graph identifiers. |
| windowsAutopilotDeviceIdentity | Register and reconcile device identities used in Windows Autopilot provisioning workflows. | Procurement systems, asset platforms, lifecycle portals | Martini validates serial and hardware identifiers, creates or updates identities through Graph, and polls or reconciles registration results. |
Authentication and security considerations
Microsoft Entra ID OAuth 2.0
Microsoft Graph uses Microsoft Entra ID OAuth 2.0 with delegated permissions for interactive applications and application roles for services, scheduled integrations, and daemon processes.
Least privilege and consent
Request only the Graph permissions required for the selected Intune resources and operations. Sensitive application permissions generally require administrative consent, and read-only and write-enabled workloads should be separated where practical.
Secrets and tenant data
- Store client secrets, tenant identifiers, and token configuration using Martini secrets-management facilities.
- Do not log access tokens, authorization headers, or complete device records unnecessarily.
- Restrict access to endpoint inventory, ownership data, serial numbers, user identifiers, and security-related state.
Operational considerations for Microsoft Intune integrations
Throttling and pagination
Microsoft Graph applies service-specific throttling. Handle HTTP 429 responses, honor Retry-After when supplied, use bounded exponential backoff, and follow @odata.nextLink rather than assuming a fixed page size.
Idempotency and asynchronous work
Use Graph IDs and stable device identifiers as integration keys. Upsert downstream objects and deduplicate repeated notifications or polling results. Treat device actions and application processing as potentially asynchronous, and do not report completion until the returned operation state confirms it.
Versions and schema changes
Prefer Microsoft Graph v1.0 for production where the required operation is available. Isolate beta-dependent mappings, distinguish deviceConfigurations from newer configurationPolicies, and test OData query combinations against representative tenants.
Testing and monitoring
- Test permissions, tenant scope, dynamic group propagation, pagination, throttling, and failure recovery.
- Monitor workflow checkpoints, correlation IDs, retry counts, and unresolved operations.
- Minimize retained endpoint data and protect operational logs.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond a script
Martini separates API consumption, workflow orchestration, mapping, business rules, target writes, and error paths so Microsoft Intune integrations can be maintained as requirements change.
Reusable integration assets
Teams can expose controlled APIs, reuse workflow logic, normalize Microsoft Graph JSON, and apply consistent authentication, validation, retry, and monitoring practices across multiple Intune use cases.
Reliable synchronization
Instead of duplicating pagination, checkpointing, throttling, and deduplication logic across point-to-point scripts, Martini provides a workflow-based implementation for scheduled polling, supported notifications, reconciliation, asynchronous operations, and downstream updates.
Frequently asked questions
Microsoft Intune is integrated primarily through Microsoft Graph REST APIs using HTTPS and JSON. Enterprise workflows can read and manage managed devices, compliance policies, configurations, applications, detected applications, and Windows Autopilot device identities. Microsoft Graph change notifications can support selected resources, while scheduled polling, pagination, filtering, and reconciliation are used where event coverage is unavailable.
Yes. Martini can integrate with Microsoft Intune by consuming Microsoft Graph REST APIs, authenticating with Microsoft Entra ID OAuth 2.0, orchestrating scheduled or event-driven workflows, mapping Graph JSON, and exposing normalized APIs to downstream applications.
No dedicated Microsoft Intune connector is required. Martini can use Microsoft Intune's confirmed native integration mechanisms, including Microsoft Graph REST APIs, Microsoft Entra ID authentication, supported change notifications, scheduled polling, JSON batching, and specialized application-content APIs.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Microsoft Intune. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Microsoft, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
Microsoft Graph REST APIs are the primary and recommended integration method. Use Microsoft Entra ID OAuth 2.0 with least-privileged delegated permissions or application roles. Use change notifications only for resources with confirmed support, and use scheduled polling for broader synchronization and reconciliation. Microsoft Graph JSON batching and specialized application-content APIs can support suitable secondary workflows.
Only selectively. Microsoft Graph change notifications are resource-specific and should not be treated as a universal Intune event stream. The required resource and event must be verified before using subscriptions; otherwise, Martini can run a scheduled workflow that polls Graph with pagination, state tracking, filtering, and idempotent processing.
Martini can retrieve paginated Graph collections, follow @odata.nextLink, optionally use supported filters or incremental mechanisms, and map objects such as managedDevice or mobileApp into a canonical model. Stable Graph IDs and device identifiers support idempotent upserts. Incremental or delta synchronization must be confirmed separately for each resource.
Yes. Martini can expose a controlled API that accepts normalized requests from portals or business systems, validates authorization and input, calls the appropriate Microsoft Graph Intune resource, handles asynchronous processing and errors, and returns a consistent response without exposing Graph implementation details to every consumer.
Related Martini documentation
Workflows
Data Processing
Connect Microsoft Intune with Martini
Use Martini to build secure, maintainable Microsoft Intune integrations through Microsoft Graph, scheduled workflows, supported change notifications, data mapping, and controlled APIs.