Skip to main content
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. Starting the run step also moves the WIP assembly, and any inventory installed on it, to the run step’s location. 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. This location move is on by default. To keep inventory where it is when a step starts, turn on Disable auto location update on run start. See Disable auto location update.

Fill in fields

Each run step can have any number of fields defined on the procedure. For each field type, see Step field types. 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: you can complete the run step.
  • Out of range: 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 list on the Part installs tab in the run’s right rail. A requirement’s Installed count sums the installed quantity across every recorded install, not the number of installs. A requirement whose quantity is 0 is an as-required part, such as adhesive or a shim. It reads As required in place of a required count. A 0-quantity requirement never blocks completing the run step or the run, and its install control stays available after it reads 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 installable. A scan is accepted when the status is Available, Kitted, or Safety reviewed, and Kitted stock only when it is kitted to this run.
  • Records the install and links the part inventory to the parent’s aBOM.
  • Moves the installed inventory to the assembly’s location. Afterward, moving the assembly moves all installed inventory with it, through the full depth of the aBOM.
  • Counts down the requirement’s remaining quantity.
The install picker asks a wider question: it offers inventory with available quantity, plus stock kitted to this run. Scrapping stock, or kitting it to another run, reduces the quantity available to install, so once nothing is left the picker stops offering it. Kit stock reserved for a different run isn’t shown either. When the list holds a lot Kitted to this run, the picker groups kitted stock under From kit and the rest under Other inventory.
Stock kitted to this run is offered whatever its status, so a lot that was kitted and then scrapped or marked unavailable still appears. It never groups under From kit, since only Kitted stock does. Read each candidate’s status badge before selecting it.
The Hide complete toggle hides requirements that are fully installed, and an as-required requirement stays visible until something is installed against it. View all opens the full aBOM in the Part Installs (aBOM) dialog. For editing the aBOM there, see Edit build requirements. When all build requirements on a run step are satisfied or explicitly excepted, the run step is ready to complete.

Edit a run step’s build requirements

Depending on your settings, the Part installs section becomes editable while the run step is in Redline, so a change to what the step installs is captured as a redline like any other run step change. Putting the step into redline and taking it out is done from the run step’s own actions, not from this section. For more information, see Redlines and deviations. While the step is in redline, you can:
  • Change a requirement’s quantity for this step, in place on the requirement.
  • Remove a requirement from the step, which leaves the part on the aBOM.
  • Add a part with the add-part control (+) in the section header. The picker separates the two outcomes into groups, and one search box narrows both:
    • On this assembly lists the assembly’s existing build requirements that this run step doesn’t already carry. Picking one only maps it to the run step.
    • All other parts carries the note Adding one also adds it to the assembly’s requirements. Picking one creates the build requirement on the aBOM first, then maps it to the run step.
    To create the new requirement as made on assembly, turn on the Made on assembly switch in the picker’s footer before you pick. It applies only to parts added to the assembly, so an existing requirement keeps how it was created, and the switch resets each time the picker closes. For more information, see Made on assembly (MOA).
  • Add a substitute that applies to this step only, from the Substitutes section header.
The install controls are hidden while the section is editable, because the step is locked for execution during an edit.

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:
  1. Check in to the run step, then click Complete.
  2. ION records who completed the run step and when, checks you out, and updates the run step status to Complete.
  3. 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.

When required installs block completion

When a build requirement is what’s holding the run step back, the error names each one and what’s unmet:
  • The part is short on quantity, with how much is required and how much is installed.
  • Reference designators have no install, listed by designator.
  • Reference designators are installed on only some of the parent units, with the count for each.
  • A made-on-assembly sub-assembly isn’t fully installed, with its percentage and which of its children are incomplete.
The percentage the aBOM shows counts quantity only. A requirement whose quantity is fully installed can still read 100% and block the run step, because one of its reference designators has no install against it. The error names the designators in that case.
Error message stating a step cannot be completed because it still has unfulfilled required installs, listing for each of two units the part short on quantity and the reference designators with no install.

The error shown when required installs block a run step. Each unmet requirement names the unit it belongs to, the part, and what is outstanding.

In a run batch, the requirement blocking the run step often belongs to a sibling unit rather than the one in front of you, so each part of the error names the unit it came from. Serialized units are named by serial number and lot-tracked units by lot number. A unit with neither is identified only as another unit in the batch, so if your units aren’t serialized or lot-tracked, open the batch to find the one that’s short.

Fail a run step

When you hit an outcome that can’t be passed, open the run step’s More actions menu and:
  1. Click Fail Step.
  2. Provide a reason as free text, with an optional issue link.
  3. 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, then open the run step’s More actions menu and click Move to To-Do to work it again. To change the run step before you rework it, click Put Step into Redline instead. Depending on your settings, Move to To-Do requires every issue on the run step to be Resolved first.
  • 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.

Attachments

Attach files to a run step, such as images, PDFs, and STEP/STP files, up to 100 MB each. These are separate from any file captured in a File field.
  1. On the run step, open the Attachments section.
  2. Add a file by dragging it onto the upload area, clicking Browse files, or clicking Take a photo on a device with a camera.
To remove a file, use its delete control and confirm in the Delete attachment? dialog.

Run step redlines

Mid-run, you can redline the procedure: add a run step, modify a run step’s fields, or correct an instruction. For more information, see Redlines and deviations.