Overview - ION Manual
Runs 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 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. Shortcut cards above the table filter it to My Runs or Overdue Runs, jump you to a Workcenter queue, or open Create Run. The My Active Sessions button opens your open check-ins so you can review or close them from one place.
Selecting runs in the table reveals a toolbar of bulk actions:
- Batch and Unbatch group or ungroup the selected runs.
- Export downloads the selected runs as a CSV.
- Print Barcodes prints labels for the selected runs’ inventory.
- Archive removes the selected runs from the main list.
- Cancel cancels the selected runs and their steps.
Run steps
A run step is the unit of floor work, each with header, typed fields, build requirements, 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. Operators can also process a queue of open steps for one location.
A run opens into three tabs: Overview, Steps, and Dependencies.
States
Each run step carries a state. The run has no state of its own. Its status is derived from its steps.
| State | What it means for a step | When the run shows it |
|---|---|---|
| Todo | No work done yet. Initial state on creation. | All steps Todo. |
| In Progress | Started by a user, records the run’s start time. | Any step In Progress. |
| Hold | Administrative pause that blocks work. | Any step Hold. |
| Redline | Editable and cannot be run. | Any step Redline. |
| Completed | All required fields filled and all work done. | All steps Completed. |
| Failed | A part or process found non-conforming. | Any step Failed. |
| Canceled | Skipped work. | All steps Canceled. |
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. Batch at creation to avoid divergence between batched and unbatched siblings.
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, the run takes the earliest start and latest end of its steps.
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.
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.
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.
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. A deviation is an accepted out-of-range measurement recorded with a rationale.
Labels
Labels are shared tags you apply across ION to group related records. To label a run, click Labels in the run header, then type in the Search or create labels… box and select a label.
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 and every required field has a value.
Your org can add custom attributes to runs for data the built-in fields don’t cover.