> For the complete documentation index, see [llms.txt](https://docs.verifone.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verifone.com/verifone-central-device-management/verifone-central/devices/registering-the-device/device-life-cycle.md). # Device life cycle Use this page to interpret device status after onboarding, registration, or later operational changes. Device lifecycle shows the current operational state of a device in **Verifone Central - Device Management**. The device status changes as the device is added, registered, assigned, inactivated, or deleted. ### When to use this page Use this page when you need to: * understand what a device status means * decide whether a device needs action * explain why a device is not yet active ### Before you start Confirm that you know: * whether the device was manually added, bulk imported, or auto-registered * whether the device already contacted the server * whether hierarchy placement is expected to be automatic or manual Use [View devices](/verifone-central-device-management/verifone-central/devices/view-devices.md) when you need to confirm the current status and related actions. ### How devices move through lifecycle states Most devices follow this pattern: 1. the record is created or prepared 2. the device contacts the server 3. the device is assigned to the correct hierarchy 4. the device remains active unless it is intentionally inactivated or deleted If a device stops at an earlier state, the missing step usually explains the current status. ### Device states #### Active The device is added to the estate, assigned to the correct node, and operating normally. This is the expected state after successful registration and placement. Next action: * review device details only if you need to investigate alerts, rollouts, or device health #### Pending Registration The device record exists in Device Management, but the device has not yet registered with the server. Use this state to identify devices that were added before first contact. Next action: * confirm the device can contact the server * confirm you did not intend to use auto-registration without a pre-created record #### Pending Hierarchy Assignment The device is added to the estate, but hierarchy assignment is still pending. Assignment can happen either: * manually * automatically through IP address range mapping By default, these devices are placed at the root hierarchy level until assignment is resolved. Use this state to identify devices that still need correct placement. Next action: * verify hierarchy rules or move the device manually if needed #### Inactive The device remains part of the estate, but it is not currently active. This state is typically used when the device is out for repair or held in a spare pool, but may return later. If the device contacts the server again, its status automatically changes to either **Active** or **Pending Hierarchy Assignment**. If automatic device movement is enabled, the device also moves to the correct hierarchy node. **Inactive sub-statuses** The system can mark an inactive device with these sub-statuses: * **Device Swapped** — the device has been replaced * **Device Missing** — the device has not contacted the server for a defined period Next action: * keep the device inactive if it may return * review the sub-status when you need to explain why it left service #### Deleted The device is removed from the estate, but its record is retained for audit purposes. Deleted device details remain available through **Deleted Devices** in the UI. If a deleted device sends a heartbeat: * the server ignores the heartbeat * the system generates a **Deleted Device Contacting** alert The device is not expected to reconnect in normal operation. Its application parameters are retained, and the device can be restored from **Deleted Devices** if it was deleted by mistake. Next action: * restore the device only if it was deleted by mistake * leave it deleted if it should no longer be managed {% hint style="info" %} Use **Inactive** when the device may return to service. Use **Deleted** when the device should no longer be managed in the estate. {% endhint %} ### How to interpret the most common states Use these quick checks: * **Pending Registration** — the record exists, but the device has not completed first contact * **Pending Hierarchy Assignment** — the device exists, but placement still needs to be resolved * **Active** — registration and placement completed successfully * **Inactive** — the device stays in the estate, but is not currently in service If the device state does not match the expected workflow stage, review onboarding, registration, or hierarchy setup. ### Common problems to check Use these checks to narrow the issue: * **A manually added device is still pending** — confirm it completed first contact * **An active device is in the wrong node** — confirm hierarchy mapping or move it manually * **An inactive device became active again** — confirm whether it contacted the server after being held or repaired * **A deleted device generated an alert** — confirm whether the hardware should still be trying to contact the server ### Result The lifecycle status shows where a device stands operationally and what action, if any, is needed next. ### Common lifecycle tasks Use these pages to act on lifecycle status: * [Onboard a Device](/verifone-central-device-management/verifone-central/devices/onboard-a-device.md) — add new devices to the estate * [Registering the device](/verifone-central-device-management/verifone-central/devices/registering-the-device.md) — complete first-time device registration * [View devices](/verifone-central-device-management/verifone-central/devices/view-devices.md) — review device status and manage device actions ### Next steps * [Registering the device](/verifone-central-device-management/verifone-central/devices/registering-the-device.md) — complete first-contact registration * [Device heartbeats](/verifone-central-device-management/verifone-central/devices/registering-the-device/device-heartbeats.md) — understand ongoing device check-ins * [View devices](/verifone-central-device-management/verifone-central/devices/view-devices.md) — review and act on current status --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verifone.com/verifone-central-device-management/verifone-central/devices/registering-the-device/device-life-cycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.