The Device Reprovision workflow wipes a network switch back to factory state via an API-driven factory reset and re-runs the ZTP process against it, then takes a fresh configuration backup once the device is provisioned. It is the recovery action when a device is still up and running, still reachable over its management IP, but its on-box configuration can no longer be trusted to match its intended state in Nautobot.
This workflow is not for devices that are already factory-reset or have been physically replaced — those boot with no configuration and run through ZTP automatically on first power-up. Use Reprovision only when the device still has a configuration that needs to be wiped over API.
Reprovision factory-resets the target switch to initiate ZTP. Before starting, manually confirm that the intended configuration exists in Config Store, Nautobot has the correct serial number and management identity, DHCP/ZTP paths are healthy, required OS images are present, and the maintenance window allows the device to go offline.
Typical reasons to reprovision a device:
Before running Reprovision, confirm the following are in place:
ztp_enabled flag on the Config Manager Info tab).The workflow form takes the following inputs:
After submission, a status page appears showing each stage as it runs. The workflow typically completes in 10-35 minutes, depending on how long the device takes to ZTP and how large the backup is.
The workflow runs two stages in order. Each stage is defined as a Pydantic-validated input and runs against the device identified by device_id. Neither stage requires manual approval.
execute_ztp — Reset the device and run ZTP.
This stage drives the full ZTP cycle:
Fetches the device record from Nautobot to confirm it exists and to attach device search attributes to the workflow for observability.
Calls the execute_ztp activity, which triggers a factory reset on the switch. The switch reboots, requests DHCP, and downloads its boot script and rendered configuration from the ZTP service. See Network ZTP for how this works under the hood.
Polls ZTP status for up to 30 minutes (with a 5-minute buffer), heartbeating every 3 minutes so that a hung activity is detected and retried promptly. The poll uses the ZTP execution timestamp captured during the reset so that it can verify the reboot actually happened and is not reading a stale “success” state from the previous provisioning.
Activities retry up to 3 times on transient errors; ZTP failures surface as ApplicationError.
If ZTP does not complete within the 30-minute window, the stage fails with ZTP failed to complete within 30 minutes, check the device logs for details. See Common issues below.
perform_backup — Capture the post-provision configuration.
Once ZTP succeeds, the workflow starts the Configuration Backup workflow as a child workflow against the same device, with trigger=WORKFLOW and a 10-minute run timeout. The child workflow ID is recorded on the parent so you can drill into the backup run from the Reprovision status page.
The backup gives you a known-good starting point for future change tracking on the freshly provisioned device.
After both stages complete, the workflow archives its results and returns success.
Confirm the reprovision succeeded by checking all of the following:
display: "ZTP completed successfully" and display: "Configuration backup completed via workflow <id>.".ZTP failed to complete within 30 minutes.
The execute_ztp stage gives ZTP a hard 30-minute deadline. If it expires, the device either never received DHCP, never reached the ZTP service, or stalled partway through. Work through the Monitoring DHCP and ZTP and Common errors sections of the New Site Bringup guide, filtering logs by the device’s UUID, MAC, or uplink IP. The most common causes for an otherwise-healthy device are:
Device is stuck and the workflow is still running.
If the device is unreachable, the ZTP activity will continue heartbeating until the 30-minute timeout. You do not need to cancel the workflow to investigate — log into the device via console or upstream SSH (see Options for logging into a stuck device) and inspect /var/log/autoprovision. If you fix the underlying issue before the timeout, ZTP will retry and the workflow will complete normally.
ZTP completed but the backup child workflow failed.
The device is provisioned and in service, but no fresh backup was captured. Open the child workflow link from the Reprovision status page to see the backup failure, then re-run the Configuration Backup workflow against the device once the underlying issue is resolved.
Reprovision is the wrong tool.
If the device’s configuration has only drifted slightly, a full reprovision is overkill — re-render and re-apply the device’s configuration instead. Reprovision is for reachable devices whose on-box state can no longer be trusted and need to be wiped via API and re-ZTPed; freshly replaced or factory-reset devices ZTP automatically without this workflow.