Operation history & recovery
Follow a command from recorded intent to device outcome, and handle unknown delivery without duplicate actions.
On this page
Operation history records administrative requests to your management engine. It is separate from the device's own execution evidence. Use both when verifying enrollment changes, profile delivery, sync, lock, or wipe.
Read a record
The native MDM page shows each operation's action, target, status, message, UTC time, and ID. Record the ID before investigating an error. Profile content, credentials, and raw Apple response bodies are excluded from the journals.
| State or outcome | Interpretation | Next step |
|---|---|---|
| Recorded intent | Beam recorded the request before dispatch | Follow the same operation rather than creating another |
| Queued / dispatching | Delivery is pending or in progress | Check connectivity and the appropriate channel |
| Accepted | The provider or execution path accepted the request | Wait for device evidence and verify the endpoint |
| Unknown / unconfirmed | A timeout or interruption prevented a trustworthy conclusion | Inspect provider, OS state, and worker receipts before retrying |
| Reported outcome | The channel supplied an acknowledgement or result | Verify the actual device effect for high-impact operations |
Exact state names vary between provider operations and response journals. Do not infer completion solely from a successful HTTP response.
Prevent duplicate dispatch
The service records durable intent and idempotency before mutations. A per-device response journal admits one outstanding command. Requests use stable IDs and preserve their recorded outcomes; crashes and timeouts do not automatically trigger retries.
The response journal retains the last 50 commands per device. The durable administrative ledger preserves operation and request IDs without automatic expiry. Your operator must preserve it and worker receipts across upgrades and recovery.
Cancel only where supported
An uncollected Windows response command can be cancelled atomically against collection. Once the worker collects it, cancellation is unavailable. Uncollected requests expire after ten minutes.
Apple response commands do not expire or support cancellation in Beam after being queued in NanoMDM. A device that reconnects later may still execute them. Disabling a binding does not undo an action already accepted by the operating system.
Investigate an unknown result
- Stop further action on the device and record the operation ID and intended target.
- Check the provider's queue and device check-in information.
- For Windows response, inspect the protected receipt and actual OS state.
- For Apple response, inspect NanoMDM delivery and the authenticated callback path.
- Have the deployment operator reconcile the outcome using retained evidence.
Do not delete the ledger, remove response receipts, or use a second wipe as a diagnostic. If a post-dispatch audit write fails, keep the recorded intent ID and follow the warning to investigate provider state.