Bulk Runs

A bulk run sends the same command, with the same parameter values, to up to 50 assets. It goes out in batches: a small canary first, then the rest, with a stop rule that aborts the run when too many commands fail. Nothing is sent until you press Send on the last step.

Opening the wizard

Open Command, then Execute Command. The Overview's Run a command button opens the same page, and Run on ready assets on Coverage opens it with that site already chosen. Operators and admins can send bulk runs.

The wizard has five steps: Command, Targets, Parameters, Rollout and Review. Next moves on once a step is complete, and Back returns to the previous step without losing what you entered.

Step 1: Command

Choose the command to send. Commands are grouped by category, one card per command key, each with its risk, description, type and key. A command declared on several templates appears once. If its risk differs between assets, the card shows each risk and says Risk differs between assets.

A line above the cards says what your organization's two-person approval setting means for critical commands sent individually. It does not change anything in a bulk run, because critical commands are never sent in bulk.

Step 2: Targets

1. Choose a site. The list shows the site's assets that are Ready for the chosen command.
2. Search by name or alias to narrow the list.
3. Select the assets. Show not ready also lists the assets that are not ready, each with its reason and the link that fixes it.

You can choose assets at more than one site: the selection is kept when you switch site. A line above the list counts how many selected assets can be commanded, for example "3 of 4 selected can be commanded". The most one bulk run can target is 50 assets. Clear selection empties it.

Each asset also says whether the command is critical on it, which matters because a critical command cannot be sent in bulk. When the site on screen, or the site or gateway of a selected asset, is under local control, a banner says so.

Step 3: Parameters

Enter the command's parameters, with their units and ranges. The same values are sent to every asset. A command without parameters says it takes none.

Step 4: Rollout

Set how the command rolls out across the assets, batch by batch. The defaults are already filled in.

The step shows the batch plan, for example "4 batches: 1, 5, 5, 1", and the policy as a sentence. A value outside its range is named under the field, and Next stays unavailable until it is fixed.

How the stop rule counts:

• The rate is the failed commands divided by every command the run has attempted so far, across all settled batches. A command refused before it was sent, for example to an offline gateway, counts as failed.
• The run aborts only when the rate is above the threshold. With the default 20 percent, 1 failure out of 5 does not abort the run.
• A read-back mismatch is not a failure. The command completed, so a mismatch does not count toward the threshold. Check mismatches on the run's records.
• 0 aborts on the first failure. 100 never aborts on its own.
• The rule is checked after each batch, starting with the first. A failure in the last batch ends the run as Partly failed or Failed rather than Aborted, because nothing is left to hold back.

Step 5: Review

Review states the request in sentences: the command and its values, how many assets at how many sites, the rollout policy and the batch plan. Below them:

• Targets lists the assets the command will be sent to.
• Left out: not ready lists the selected assets that are not ready, with the reason for each. They are not part of the request.
• For a high-risk command, type the command's exact name to confirm. Fleetera checks it again on the server.
• A critical command cannot be sent: Review says Critical commands are not sent in bulk and links to each asset, where the command can be sent one asset at a time. This holds whether or not your organization requires an approver.

Select Send to create the run. Its run page opens. If Fleetera refuses the request, Review says why, and nothing is sent. For example, if a selected asset's site or gateway came under local control after you chose it, the whole request is refused.

The run page

Every run has its own page, opened from Bulk runs or from any of its commands' records. The header names the command, the run's status, who requested it, through which origin and when.

The page shows the policy, a tile for each batch with how many of its commands have settled, the counts so far, including read-back mismatches, and every command in the run grouped by batch. Each command links to its own record. If any command in the run was refused because its target was under local control, an alert says how many and why.

Pause, resume and abort

Operators and admins control a running run from its page:

• Pause stops the run after the batch that is running. Until then the page says "Pause requested; the run stops after the batch that is running."
• Resume continues a paused run with its next batch. If the command's risk rose while the run was paused, Resume is refused and the run stays paused: abort it and send a new request that confirms the new risk.
• Abort asks for confirmation and an optional note. No further batch starts. Commands already sent finish on their own, because a sent command cannot be recalled.

The controls appear only on a run that has not finished, and not on runs created before staged rollout, which show Not staged on the Bulk runs page.

Run statuses

Each command in a run follows the same statuses as a command sent to one asset. Past runs are listed on Bulk runs.