Overview

A procedure is a versioned sequence of steps used to build, test, or inspect a part. You author and revise it in the procedure editor, release it through a controlled review, then create runs against it on the floor. A run is a copy of the procedure at the moment it starts. Later procedure revisions do not flow into runs already in progress, so each run stays an accurate record of what was done. Steps hold the work instructions and capture operator input inline through structured fields. You reuse shared work through standard steps, link a procedure to the parts it produces or inspects, and constrain execution order through step dependencies.

​

Steps

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

• Content: written instructions in a rich-text box, with attachments and inline fields.
• Datagrid: a table of typed cells an operator fills in when the procedure runs.

Steps nest up to five levels deep to group related actions, such as inspecting each part of an assembly under one parent. 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. 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.

• Procedure attributes appear in the Configuration section of the procedure’s Overview tab and stay editable at any time. When a run is created, a run attribute of the same name inherits the procedure attribute’s value.
• Step attributes appear inline in the step editor while the procedure is a draft. Their values copy to run steps, where you can edit them through a redline.

​

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 Nested steps and standard steps.

​

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