Run Controls
This page covers intent settings that apply during the run lifecycle — from creation through step execution to intent updates and inspection runs.
Required at Run Create
Setting key: requiredAtRunCreate
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
enabled
true / false
Turns the check on or off. Default: false
procedureTypes
Procedure type identifiers
Limits enforcement to the listed procedure types. Leave empty to apply to all run types.
Notes
When procedureTypes 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 procedureTypes: ["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: requiredAtRunStepStart
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
enabled
true / false
Turns the check on or off. Default: false
procedureTypes
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 requiredAtRunCreate 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 requiredAtRunStepStart 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: requiredOnRunIntentUpdate
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
enabled
true / false
Turns the check on or off. Default: false
procedureTypes
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 procedureTypes 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 requiredOnRunIntentUpdate 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: runIntentSideEffect
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
enabled
true / false
Turns the check on or off. Default: false
downgradeInventoryOnMismatch
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
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 downgradeInventoryOnMismatch (see below).
downgradeInventoryOnMismatch behavior (applies only when run intent is lower quality than inventory intent)
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 runIntentSideEffect 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, downgradeInventoryOnMismatch controls the outcome:
With
downgradeInventoryOnMismatch: true: the assembly inventory is downgraded from Flight to Development to match the run.With
downgradeInventoryOnMismatch: 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.
Is Inspection Run Required
Setting key: intentOption.isInspectionRunRequired
What it does
When a part is added to a receipt, ION automatically creates inspection runs for any inspection procedures associated with that part.
This setting controls whether those inspection runs are required for a given intent option.
When inventory is added to a receipt, ION checks the inventory's intent:
If the inventory has no intent set, inspection runs are created.
If the inventory's intent has
isInspectionRunRequired: true, inspection runs are created.If the inventory's intent has
isInspectionRunRequired: false, inspection runs are not created.
Unlike the other intent settings in this section, this one is configured per intent option rather than globally. That allows you to require inspection runs for some intents while skipping them for others.
Notes
This setting applies at the intent option level, not at the run level.
If inventory has no intent assigned, inspection runs are still created by default.
This setting only affects whether inspection runs are automatically created during receipt. It does not prevent users from creating inspection runs manually later if needed.
Example scenarios
Scenario 1 — Flight inventory requires inspection
A receipt includes an ASME pressure fitting, which has an associated inspection part procedure. The received inventory is assigned the Flight intent, and that intent option has isInspectionRunRequired: true.
When the PO line is added to the receipt, ION automatically creates the inspection run.
Scenario 2 — Development inventory does not require inspection
A receipt includes ASME pressure fitting PN, which has the same associated inspection part procedure. The received inventory is assigned the Development intent, and that intent option has isInspectionRunRequired: false.
When the PO line is added to the receipt, ION does not automatically create an inspection run.
Last updated
Was this helpful?