Usage guide: Battery replacement scheduling
This workflow will automate the process of identifying device batteries in need of replacement, checking the warranty status of the battery and device, and following approval from the end user, updating a pre-defined ITSM ticket for battery replacements.
Ensure your workflow is properly configured by following the steps highlighted in its configuration guide:
Configuration guide: Battery replacement scheduling
Workflow Structure
This section describes the key steps in this workflow. The first check is for the device operating system. Whilst the same remote action is run for both operating systems the output checked is different.
macOS
The remote action “Get battery status” is run on the device and the “Battery condition” output is analyzed. This is a feature built-in to macOS and there are two states:
Normal: The battery is functioning normally.
Service recommended: The battery is performing normally, but its ability to hold a charge is less than when it was new. You may want to consider replacing the battery.
The campaign “Battery replacement advisory” is sent to the user to inform them that their battery has been identified as being in need of replacement. They must then confirm whether or not they need or want a replacement battery. If they refuse then the workflow will end.
If the campaign is accepted the next step is to update the ITSM ticket configured as a global parameter with the device name, and the battery condition output from the remote action.
 |  |
Windows
The remote action “Get battery status” is run on the device and the “Battery health” output is analyzed.
Battery health is considered good when it is above 60%, in this case the workflow terminates.
Battery health is considered poor when it is below 60%. The workflow continues.
The battery cycle count of devices with poor battery health is now analyzed.
A cycle count of under 300 is considered good, in this case the workflow terminates.
A cycle count of over 300 is considered bad, in this case it is determined that the battery should be replaced.
The remote action “Get warranty status” is run on the device to check whether or not the device is under warranty, and if so, whether the battery is also under warranty. In this case, a ticket can be logged to request a replacement battery under warranty.
Devices with an expired warranty now face a further check from the “Get warranty information” remote action. The output “Device age in years” is checked for the device. If the device is more than four years old (this device age can be customized within the workflow if required), then it may not be worth replacing the battery. For these devices, the workflow is terminated.
For all devices that pass these hardware checks, the next step is to send the campaign “Battery replacement advisory” to the user to inform them that their battery has been identified as being in need of replacement. They must then confirm whether or not they need or want a replacement battery. If they refuse then the workflow will end.
If the campaign is accepted the next step is to update the ITSM ticket configured as a global parameter with the device name, the battery health and cycle count values, and the workflow condition that applies.
Related topics
For more information on the battery status of devices in your organization, Nexthink has released the built-in dashboard, Battery Health. This dashboard extends your diagnostic capabilities by providing a dedicated dashboard that focuses on battery health insights. This includes key insights about battery inventory, health, and status to help make data-driven decisions to identify batteries that need to be replaced and to improve their battery life.