[FEATURE REQUEST] Optional pre-enrollment inventory sync (Autopilot / Apple DEP / corporate identifiers)

[brngates98]

Problem or use case

intune2snipe currently only creates/updates Snipe-IT assets for devices that already show up in GET /deviceManagement/managedDevices — i.e. devices that have actually enrolled in Intune. There's no visibility into hardware that's been purchased and is sitting in inventory but hasn't been unboxed/enrolled yet:

• Windows devices registered in Windows Autopilot but never enrolled
• iOS/iPadOS/macOS devices assigned via Apple Business Manager / Apple School Manager (DEP) but not yet enrolled
• Any platform (including Android) staged via Intune's manually-uploaded corporate device identifiers (serial/IMEI allowlist)

For orgs that want full asset-lifecycle tracking in Snipe-IT — from "we bought it" through "it's deployed to a user" — this is a real gap. The goal is "ultra completeness": a Snipe-IT asset should exist for a device the moment it's known to the organization, not just once someone unboxes it.

Proposed solution

Add an optional pending-enrollment inventory pre-sync, in the same shape as the Entra user pre-sync added in #33 (disabled by default, env-var gated, runs as an independent pass that doesn't change existing behavior when off).

New env vars (proposed):

Variable	Purpose
SNIPEIT_TRACK_PENDING_ENROLLMENT	Set to true to enable the pre-enrollment inventory pass (default: false)
SNIPEIT_STATUS_PENDING_ENROLLMENT	Status label for placeholder assets (default: Pending Enrollment, auto-created like the other lifecycle statuses)
SNIPEIT_PENDING_ENROLLMENT_SOURCES	Comma list of sources to pull from: autopilot, dep, corporate (default: all three)

Data sources (Microsoft Graph, beta unless noted):

1. Windows Autopilot — GET /deviceManagement/windowsAutopilotDeviceIdentities (already fetched today for lifecycle reconciliation, just not used to create assets). Also carries groupTag and purchaseOrderIdentifier, currently unused.
2. Apple DEP/ABM — GET /deviceManagement/depOnboardingSettings (one per Apple token — Business Manager and School Manager tokens can coexist, so iterate all) → .../importedAppleDeviceIdentities. Gives serialNumber, platform, enrollmentState, isSupervised, discoverySource.
3. Manually-staged corporate identifiers — GET /deviceManagement/importedDeviceIdentities. Cross-platform (this is the practical Android story — Google's zero-touch portal itself isn't reachable via Graph, but IMEI/serials uploaded to Intune's corporate identifier list are).

All three expose a serial (or IMEI) plus an enrollmentState (unknown/notContacted/pendingReset/failed/blocked/enrolled) and platform — a consistent, minimal shape.

Sync behavior:

For each identifier from an enabled source where enrollmentState != "enrolled" and no existing Snipe asset matches the serial, create a minimal placeholder asset: serial, platform-derived category, status Pending Enrollment, no checkout. Because the existing sync_device flow already matches assets by serial number on every run, this requires no new dedup logic — the day the device actually enrolls in Intune, the normal sync finds the placeholder by serial and fills in the rest (model, user, custom fields, checkout) in place.

Symmetrically, if a placeholder's serial later disappears from its source (order canceled, device returned) while still un-enrolled, archive it the same way reconcile_missing_devices already does for devices leaving Intune.

Smaller, related wins to fold in if we're touching this area:

• Map Autopilot groupTag → Snipe location/department (auto-provision based on deployment group) and purchaseOrderIdentifier → Snipe's built-in order_number field.
• A few more managedDevice properties as optional custom fields via the existing generic mapping mechanism (isEncrypted, jailBroken, totalStorageSpaceInBytes, physicalMemoryInBytes, deviceRegistrationState) — cheap since the custom-field plumbing already exists.

Permissions: Likely reuses the DeviceManagementServiceConfig.Read.All scope already required for Autopilot (same Intune "Enrollment" permission category as importedDeviceIdentities and depOnboardingSettings) — needs verification against current Graph docs at implementation time.

Alternatives considered

• Do nothing / require devices to be manually pre-created in Snipe-IT before enrollment — defeats the purpose of automated sync and is the same friction [FEATURE REQUEST] Optional Entra user sync before asset sync #33 was trying to remove on the user side.
• Only support Windows Autopilot (data we already fetch) — cheaper, but explicitly not "ultra complete" since it ignores Apple DEP/ABM and the cross-platform corporate-identifiers path, which is the intent here.

Primary area

Microsoft Graph / Intune

[warst]

This makes sense to me as an optional feature, and I like that it would be disabled by default so the current behaviour remains unchanged unless someone specifically wants it.

From my side, the main benefit would be closing the gap between a device being known to the organisation and it actually enrolling into Intune. For anyone using Snipe-IT as the full asset lifecycle record, it would be useful for an asset to exist from the point the device is purchased or staged, rather than only after it has been unboxed and enrolled.

The general approach sounds right to me:

• keep it env-var gated
• create only a minimal placeholder asset
• use a Pending Enrollment status
• do not check the device out to anyone at that stage
• let the existing serial matching update the same asset once it later appears as a managedDevice

I also like the idea of using the existing sync behaviour as much as possible rather than adding a separate deduplication model. If the placeholder can simply be matched and filled in properly once the device enrols, that feels clean.

The only areas that stood out to me as things that may need a bit of care are the edge cases, particularly where a device exists in more than one pending source, or where a corporate identifier is IMEI-based rather than serial-based. I’m sure you have already thought about this, but the archive-on-disappear logic would probably want to be limited to assets created by this pending-enrolment pass and still in that placeholder state, so it doesn’t interfere with anything manually created or already synced properly.

The smaller additions also sound useful, especially mapping Autopilot groupTag and purchaseOrderIdentifier where available. Those would add useful lifecycle context without changing the core sync behaviour.

Overall, I think this would be a good fit as a feature-gated pre-sync option. It would not change the normal enrolled-device workflow, but it would give organisations that use Snipe-IT for full lifecycle tracking a cleaner way to represent devices before they are actually enrolled.