Run Controls

This page covers intent settings that apply during the run lifecycle — from creation through step execution to intent updates and inventory installation.

---

Required at Run Create

Setting key: required_at_run_create

What it does

Required at Run Create forces users to specify an intent designation when creating a run. Without this setting, intent is optional at run creation.

This ensures that every run starts with a clear quality designation, which downstream settings like Run Intent Side Effect can then use to automatically stamp intent onto inventory.

You can apply this requirement to all runs or scope it to specific procedure types.

When it runs

• At run creation time — when a user submits the new run form.

Configuration options

Field	Possible Values	Description
enabled	true / false	Turns the requirement on or off. Default: false
procedure_types	Procedure type identifiers	Limits enforcement to the listed procedure types. Leave empty to apply to all run types.

Notes:

• When procedure_types contains specific values, only runs of those procedure types require intent. All other run types remain optional.

Example scenario

Your organization only requires intent on Build procedure types. Set enabled: true and procedure_types: ["build"]. Users creating a Build run must select an intent. A user creating an Inspection run will not be required to select an intent.

---

Required at Run Step Start

Setting key: required_at_run_step_start

What it does

Required at Run Step Start prevents a technician from starting a run step unless the run has an intent designation set. If the run's intent field is empty, the step start action is blocked until intent is assigned.

This setting is useful when intent might not be required at run creation but must be confirmed before any active work begins. It serves as a second enforcement point — catching cases where a run slipped through creation without intent.

When it runs

• When a user attempts to start a run step — the check occurs at the moment the step start action is triggered.

Configuration options

Field	Possible Values	Description
enabled	true / false	Turns the requirement on or off. Default: false
procedure_types	Procedure type identifiers	Limits enforcement to the listed procedure types. Leave empty to apply to all run types.

Notes:

• This setting can be used in combination with required_at_run_create for layered enforcement, or independently as a fallback check.

Example scenario

Your organization creates runs from work orders that may be auto-generated, so intent is not always set at creation. You still want to ensure intent is confirmed before a technician begins working. Enable required_at_run_step_start so that when a technician tries to start Step 1 of a run, ION checks for intent. If it is missing, the technician sees a prompt to set it before proceeding.

---

Required on Run Intent Update

Setting key: required_on_run_intent_update

What it does

Required on Run Intent Update prevents users from clearing or unsetting the intent on a run after it has been set. Once intent is assigned to a run, it cannot be removed — it can only be changed to a different intent value.

This ensures that runs always carry a valid intent designation once one has been applied. Without this setting, a user could inadvertently (or intentionally) remove intent from a run mid-execution, losing the quality designation for that work order.

When it runs

• When a user updates the intent field on a run — the check fires at the point of saving the update.

Configuration options

Field	Possible Values	Description
enabled	true / false	Turns the requirement on or off. Default: false
procedure_types	Procedure type identifiers	Limits enforcement to the listed procedure types. Leave empty to apply to all run types.

Notes:

• This setting only blocks clearing intent. Changing from one intent value to another is still permitted.

• When procedure_types is empty and enabled is true, the restriction applies to all runs.

Example scenario

A Flight-grade run is in progress. A user accidentally attempts to clear the intent designation while editing the run details. With required_on_run_intent_update enabled, the update is rejected and the run retains its Flight designation. The user can change it to a different intent (e.g., Qualification) but cannot leave it blank.

---

Run Intent Side Effect

Setting key: run_intent_side_effect

What it does

Run Intent Side Effect automatically propagates the run's intent designation to the run's inventory — the inventory record that represents the unit being built by the run.

When a run has intent set, this setting ensures the assembly inventory it produces carries that same intent, without requiring a separate manual update.

When it runs

• When intent is updated on a run — the run's assembly inventory is updated to match.

Configuration options

Field	Possible Values	Description
enabled	true / false	Turns the side effect on or off. Default: false
downgrade_inventory_on_mismatch	true / false	When the run's intent is lower quality than the assembly inventory's intent, downgrade the inventory to match the run. Default: true

Mismatch behavior

Situation	Behavior
Assembly inventory has no intent	Run intent is copied to the inventory.
Run intent is higher quality than inventory intent	Blocked — an error is raised. You cannot assign a higher-quality intent to the run than the assembly inventory already has.
Run intent is lower quality than inventory intent	Controlled by downgrade_inventory_on_mismatch (see below).

downgrade_inventory_on_mismatch behavior (applies only when run intent is lower quality than inventory intent)

Value	Behavior
true	The assembly inventory is downgraded to match the run's lower intent.
false	The assembly inventory intent is left unchanged. No side effect is applied.

Example scenarios

Scenario 1 — Run creates new assembly inventory

A Development run is created to build a prototype unit. At run creation, ION creates a new assembly inventory record for that unit with no intent set. With run_intent_side_effect enabled, the new inventory is immediately stamped with Development intent. No manual step is needed.

Scenario 2 — Existing Flight-grade inventory is assigned to a Development run

A Development run is started, but the assembly inventory associated with the run was previously designated Flight. The run's intent is lower quality than the inventory's intent, so the block does not apply. Instead, downgrade_inventory_on_mismatch controls the outcome:

• With downgrade_inventory_on_mismatch: true: the assembly inventory is downgraded from Flight to Development to match the run.

• With downgrade_inventory_on_mismatch: false: the assembly inventory retains its Flight designation. No side effect is applied.

Scenario 3 — Blocked attempting to set run intent above inventory intent

A Development assembly inventory is on the run and a user attempts to set the run's intent to Flight. Because Flight is a higher quality tier than Development, this is blocked with a validation error. The run's intent cannot exceed the quality of its assembly inventory.