To run a step, open the run step, fill in the required fields, record measurements, attach evidence, and complete it. ION captures the result, propagates it to the relevant data downstream, such as analytics, traceability, and batched siblings, and unlocks the next run step. For the full set of step states and their transitions, see Run and run step states.
Check into a run step
On a Todo run step, click Start / Check In to move it to In Progress and begin capturing your labor time. While it’s in progress, Check In and Check Out let you start and stop your own session. Completing, holding, failing, or redlining it checks you out. For how check-in and check-out sessions are recorded and edited, see Time tracking.
Fill in fields
Each run step can have any number of fields defined on the procedure. Common field types:
- Number: a measurement, often paired with a validation (
min, max, target ± tolerance).
- Pass/Fail: a single-select with two options, the simplest quality gate.
- Text: free-form notes or values that don’t have a structured type.
- Date: when something happened, such as an inspection date.
- Single-select / Multi-select: pick one or many from a controlled list.
- File: attach an image, drawing, or document. For more information, see File upload.
- Boolean: yes or no.
Fields can be marked required. ION blocks run step completion if any required field is empty.
Measurements and validation
When a numeric field has a validation (target, min, or max), ION evaluates your input as soon as you save the field:
- In range: the field shows green, and you can complete the run step.
- Out of range: the field shows red, and completion is blocked unless the run step’s policy allows out-of-range values with an issue attached.
Out-of-range measurements that the team accepts with a rationale become deviations. For more information, see Redlines and deviations.
Build requirements (parts to install)
If the run step has build requirements, the parts to install onto the parent assembly during this run step, they render as a checklist below the fields. Each requirement shows:
- The part to install.
- The required quantity.
- Substitutes, if configured.
- The current install state, incomplete or complete.
You install a part by scanning its part inventory serial or lot, or by selecting from a picker. Your organization can require a barcode scan for installs. For more information, see Require barcode scanning for installations. ION does the following:
- Validates that the scanned unit matches the required part or an approved substitute.
- Confirms the part inventory is in an installable state: Available and not consumed elsewhere.
- Records the install and links the part inventory to the parent’s aBOM.
- Counts down the requirement’s remaining quantity.
When all build requirements on a run step are satisfied or explicitly excepted, the run step is ready to complete.
Sign-off fields
Approval gates are configured on the procedure as sign-off fields, an extra check before the run step can be completed. Common patterns:
- Quality Engineer sign-off on critical inspection steps.
- Witness sign-off on irreversible operations, such as fastener torque, sealing, and lid close.
- Customer sign-off for customer-witnessed builds.
Each sign-off field is tied to a role and shows Expecting approval by: that role. Only a member of that role can act on it, using Approve or Reject. A required sign-off field blocks completion until it’s approved, the same as any other required field.
Complete a run step
When fields are filled, build requirements installed, and any sign-off fields approved:
- Check in to the run step, then click Complete.
- ION records who completed the run step and when, checks you out, and updates the run step status to Complete.
- The next run step, if any, becomes the active run step for the run.
If the Complete button is disabled, ION lists what’s still outstanding (empty required fields, unapproved sign-offs, or uninstalled build requirements) so you can resolve it first. Completion is logged in the run’s transaction history with the user and timestamp.
Fail a run step
When you hit an outcome that can’t be passed, open the run step’s more-actions menu and:
- Click Fail Step.
- Provide a reason as free text, with an optional issue link.
- The run step transitions to Failed.
A failed run step doesn’t fail the run automatically. The run stays In Progress. Common follow-ups:
- Rework: fix the failure and re-run the run step. Depending on the procedure config, the run step can be reopened or a duplicate inserted.
- Disposition via issue: open an issue against the run step, capture the disposition (Use As Is, Rework, or Scrap), and let the issue lifecycle drive the next action. See Issue states.
- Fail the run: if the failure can’t be resolved at all, transition the run to Failed.
Run step redlines
Mid-run, you can redline the procedure: add a run step, modify a run step’s fields, or correct an instruction. This is core to how shop-floor reality diverges from the as-designed procedure. For more information, see Redlines and deviations.
When a step needs to pause mid-execution (waiting on a part or on QE), drop a comment on the step so the next operator picks up where you left off.