Campaign Lifecycle Flow for v2

Campaign Lifecycle Flow for HTTP Devices using the /v2 Resource Path

1. Creating a campaign starts with the user scheduling which devices with proper make, model and current software prerequisites need to be updated with which software at what date.
2. Once the user schedules a campaign request, the campaign changes to “Request Pending” status
   1. After passing parameter checks, campaign status typically moves to "Queued" status.
   2. If parameter checks fail, it moves to "RequestFailed" and may bypass "Pending." 
      Checks could include eligibility such as licenses, FOTA capable, prerequisistes or timing checks.
   3. If it is an on-demand campaign, it bypasses the "Queued" status and moves to "Scheduled."
3. The campaign normally stays in "Queued" status while the system collects requests.
   1. Once the start date has begun, it moves to "Scheduled."
   2. The user can choose to cancel the campaign in "Queued" status.
4. The campaign stays in "In Progress" during the device update.
   1. Once the campaign end date has been reached or if all devices were successfully upgraded, it moves to “ended.” For an on-demand campaign, the end date is one week after the start date.
   2. After the campaign begins but before it ends, the user could decide to “abort” the campaign. Some devices may have already been upgraded.

Device Lifecycle Flow for HTTP Devices using the /v2 Resource Path

Status and Error Messages for HTTP Devices using the /v2 Resource Path