Overview - ION Manual

Steps

A step is the unit of work in a procedure. Each step is one of two types, chosen when you create it:

When a run starts, ION copies each step into a run step that operators execute and complete in dependency order. A change to an in-progress run step goes through a redline. Steps nest up to five levels deep to group related actions, such as inspecting each part of an assembly under one parent. Depth 0 is the root level, depth 1 its direct children, and so on to the five-level limit, which also caps how deep the API can nest steps. ION numbers steps automatically from 0 by order, with dot notation for children (the first child of step 1 is 1.0, then 1.1). You can tag each step with a location to show where the work is done. To add, copy, reorder, and nest steps, see Manage procedure steps.

Fields

Both step types collect operator input through data-collection fields. A field defined on a procedure step becomes an input the operator fills in during the run.

Field type Notes
Datetime A date and time for an event, such as when a part entered a thermal oven.
Boolean A checkbox for a true/false or pass/fail response.
String Free text. No length limit, all UTF-8 characters.
Number Enforces a numeric value. Supports validations.
Select One option from a list.
Multiselect One or more options from a list.
Signoff A role-gated digital signature. Enforced by role during the run. Can require peer review ( Peer review required).
File A required file, such as a machine CSV export. Maximum 5 GB.
Tool Links use of a tool to the step for traceability. Can be limited by part number, type, and calibration status.
ION User Links an ION user to the step.
ION Part Links an ION part to the step.

Fields are optional by default. A Required field blocks step completion until filled, and a required field can also allow a Not Applicable entry for positive confirmation. Number fields support validations that check a reading against limits during the run and can trigger issue creation. For the full reference, see Step field types.

Custom attributes

Beyond the built-in fields, your org can add custom attributes to procedures and steps for data the built-ins don’t cover.

Standard steps

A standard step is a step whose work instructions are shared across procedures and revisioned independently. When you release a new version, every procedure and not-yet-started run that references it picks up the latest released version automatically, so shared work such as a torque sequence or ESD check stays in sync without redlining each procedure. A standard step disconnects from its source once its run status advances (in progress, redline, canceled, failed, or completed), freezing the run’s record at the version in use. Standard steps can be nested inside other steps and standard steps but cannot themselves take a standard step as a child. For creation, reuse, and run behavior, see Manage standard steps. For nesting patterns, see Procedure best practices.

Part links

A procedure links to one or more parts to declare which work instructions produce or inspect a given part. This is not a parts list of the assembly. With the Require part-procedure relationship org setting enabled, ION blocks run creation unless the selected part is linked to the selected procedure. For inspection-type procedures, each part link is Required or Optional, which controls whether receiving a part auto-creates an inspection run. To set up links, see Link a part to a procedure.

Dependencies

Step dependencies define the execution order between steps at the same depth in a procedure. You draw the dependency graph in the procedure’s Dependencies tab, and ION enforces it during the run so operators know which step is available, blocked, or being redlined. See Manage step dependencies.

Installation requirements

Build-type procedures can carry installation requirements on their steps, tying mBOM items to the steps that install them. A run step cannot close until its required installs are satisfied, which keeps the aBOM an accurate digital record of the physical build. This feature is in beta. See Assign installation requirements.

Review and lifecycle

A procedure moves through a controlled change process: you author it as a draft, move it In Review, and it reaches Released once reviewers sign off. For the steps to create a procedure, version it, and move it through review, see Create and release a procedure. Standard steps use the same review flow and can be revisioned on their own. You configure which reviewer roles are required per org. See Configure standard step reviewer roles. Because a run copies the procedure at start, released changes reach only runs that have not started. To hold work until instructions are final, place the run or step on hold. For patterns that combine nesting, standard steps, and holds, see Procedure best practices.

Procedure actions

The procedure header carries actions beyond editing and review, in its More options menu and side panel: