Run a step

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. 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 list on the Part installs tab in the run’s right rail. Each requirement shows:

• The part to install.
• The required quantity.
• Substitutes, if configured.
• The current install state, incomplete or complete.
• An Installed count of the units installed against it, summing the installed quantity across every recorded install rather than the number of installs.

A requirement whose quantity is 0 is an as-required part, such as adhesive or a shim. In place of a required count it reads As required, followed by the quantity installed so far. ION treats it as outstanding until something is installed against it, so it stays in the list and counts as not yet installed in the panel’s progress figure. Because there’s no target to reach, an as-required part 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: Available, or Kitted stock held in this run’s kit.
• 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 groups this run’s kit stock under a From kit section at the top, with the rest under Other inventory. Kit stock reserved for a different run isn’t shown. To narrow a long list, click the search control and type a part number, description, or an installed serial or lot to filter the requirements. 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.

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 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.

​

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.

​

Related

• Run and run step states
• Create a run
• Redline a run
• Edit build requirements
• Disable auto location update
• Line-side inventory
• Issues
• Submit a run step result