Overview

A run is one execution of a procedure against a specific part inventory. It binds three things that travel through the rest of the build: the procedure that defines the work, the part inventory the run produces or builds against, and the assignment of who does the work. The output is the as-built BOM (aBOM), the auditable record of what was built and what went into it. For a guided tour, see the interactive walkthrough. A run holds an ordered set of run steps, each instantiated from a procedure step with the same fields and validations. Operators work steps at a work center, capture readings, install parts, and sign off. The run does not carry its own start action: it moves to In Progress when the first step starts, and rolls its status up from its steps.

​

The Runs page

The Runs page lists your runs and is the entry point to everything below. A toggle in the header switches between two views: Table, the default sortable and filterable list, and Timeline, which plots every scheduled run (see Schedule a run). Shortcut cards above the table filter it to My Runs or Overdue Runs, jump you to a Workcenter queue, or open Create Run. The timer button in the header carries a count of your open check-ins and opens My Active Check-ins, so you can review or close them from one place (see Time tracking). The table’s search box, with the placeholder Search run #, title, batch, part #, procedure..., matches a substring against the run’s number, title, and description, its batch’s number and title, the part’s number, description, and revision, the procedure’s number and title, and the run’s labels. A run matching in any one of those is returned. The Due Date column counts down instead of showing a calendar date, in the two largest units that apply: Due in 3 days 5 hours while the run is in flight, Overdue by 2 days once the date has passed, and Due now or Overdue when less than a minute separates the two. A run near its date or past it is colored to flag urgency, an on-track run stays muted, and a run that has settled shows the plain date. The control in the column header switches the whole column between the countdown and the exact date, and the urgency color carries over either way. Hovering a cell shows the other form: the exact date and time in your org’s date format when the column shows the countdown, and the countdown when it shows the date. Selecting runs in the table reveals a toolbar of bulk actions:

• Batch and Unbatch group or ungroup the selected runs. See Manage run batches.
• Export downloads the selected runs as a CSV. See Export run data.
• Print Barcodes opens a menu offering Run labels for every selected run and Part inventory labels (N) for the selected runs that have a part inventory. See Print labels.
• Archive removes the selected runs from the main list.
• Cancel cancels the selected runs and their steps. Runs that are already complete or canceled are skipped.

​

Run steps

A run step is the unit of floor work. Each has a header, typed fields, build requirements (parts to install onto the parent assembly), and action buttons. Steps render in procedure order, and dependencies between them gate which are available to work. To create a run and instantiate its steps, see Create a run. To work a step through fields, measurements, sign-offs, and failure paths, see Run a step. Operators can also process a queue of open steps for one location; see Run steps at a work center. A run opens into three tabs: Overview, Steps, and Dependencies. The Dependencies tab shows the run’s step dependency graph, the same view the dependency manager uses on a procedure. On a run, changing dependencies is a redline: both steps must be in Redline to draw a link between them. See Redline a run.

​

States

Each run step carries a state. The run has no state of its own. Its status is derived from its steps. Available to work is a separate calculation: a step is available when it is in Todo or In Progress, all upstream dependencies are Complete, and its parent step, if any, is In Progress. Canceling a step removes it from the dependency graph, which rewires so downstream steps are not blocked by skipped work. Batched runs rewire each run’s graph the same way. A run never moves backward through completed states on its own. Reopening a Complete run requires admin permission and is recorded in the run’s transaction history with the user, timestamp, and reason.

​

Batches

A run batch groups runs that share steps so a sign-off, redline, or state change on one step propagates to every sibling step across the batch. Only sibling steps propagate; a step unique to one run is unaffected. Part installs do not cascade automatically. Batch at creation to avoid divergence between batched and unbatched siblings, or manage membership later. See Manage run batches.

​

Scheduling

A run carries a scheduled start, scheduled end, and due date, and each step carries its own schedule and lead time. When step schedules are set but the run’s are not, the run takes the earliest start and latest end of its steps. The Timeline view on the Runs page plots every scheduled run. See Schedule a run.

​

Splitting inventory

When a subset of units on a run develops a problem, you split those units off onto an issue and into a separate location while the rest of the run continues. ION divides inventory by how far each unit has progressed: uninstalled parts allocate to each group independently, while already-installed parts link to both groups as shared until traceability resolves them. See Split inventory on a run.

​

Outside processing

A procedure step flagged as an outside process links to a purchase order so you can send the part and operation to a supplier and receive it back into the run. Outside-process steps are not batched. See Send a step to outside processing.

​

Time tracking

ION captures operator labor as check-in / check-out sessions on each step. Starting a step checks the operator in; completing, holding, redlining, or failing it checks them out. Operators cannot check into a step that is not available to work. Session data feeds cost and cycle-time analytics and can be edited. See Time tracking.

​

Redlines and deviations

A redline is an in-flight modification to the procedure made on one run: add a step, edit a field, correct an instruction, or build a procedure as you fly. It lives on the run, not the procedure template, so it keeps the audit trail intact and can be reviewed, approved, and merged back into the procedure or other runs. A deviation is an accepted out-of-range measurement recorded with a rationale. See Redline a run.

​

Labels

Labels are shared tags you apply across ION to group related records. For creating and deleting labels in the shared library, see Labels. To label a run, click Labels in the run header, then type in the Search or create labels… box and select a label. To create a new label, type its name and select the create option.

​

Completion and review

Completing a run reconciles its accumulated state into the records downstream consumers rely on. ION blocks completion until every required step is signed off, every required field has a value, every build requirement is installed or excepted, and every required approval gate is satisfied. On completion, ION locks all step records, updates the produced inventory’s state, and feeds the aBOM, traceability, and analytics. See Complete and review a run. To pull a run’s record out for analytics, see Export run data.