# 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 | Field | Possible Values | Description | | ---------------- | -------------------------- | ---------------------------------------------------------------------------------------- | | `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 | Field | Possible Values | Description | | ---------------- | -------------------------- | ---------------------------------------------------------------------------------------- | | `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 | Field | Possible Values | Description | | ---------------- | -------------------------- | ---------------------------------------------------------------------------------------- | | `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 | Field | Possible Values | Description | | ------------------------------ | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | `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 | 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 `downgradeInventoryOnMismatch` (see below). | `downgradeInventoryOnMismatch` 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 `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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://manual-v2.firstresonance.io/quality/intent-management/run-controls.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.