Skip to main content
These patterns keep procedures maintainable as they grow in size and reuse.

​
Nesting and standard steps

  • Use standard steps for reusable or critical instructions. When a set of instructions appears across many procedures, or when updates to it must reach in-progress work before execution, make it a standard step. A revision to the standard step reaches every procedure, standard step, and not-yet-started run that references it.
  • Group related steps under one parent. Nest steps that share an intent under a single parent step, such as a “Perform standard torque operation” step that contains each torque action. This clarifies the procedure and simplifies its dependency graph.
  • Edit a standard step’s dependencies at its own root level. When you nest standard steps within each other, create and edit dependencies for a standard step in its own procedure, not in the parent that calls it. Editing “Torque bolts” within its own root keeps its dependencies consistent everywhere it’s used.
  • Keep nesting within five levels. ION allows up to five levels of nesting. The limit also protects procedure creation through the API, which could otherwise create hundreds of levels and degrade performance. As procedures get deeper, reassess whether the structure stays readable.

​
Hold work until instructions are final

Combining nested standard steps with the run On hold status lets planners schedule work before every instruction is finalized, while preventing operators from starting a step whose instructions aren’t ready.
  1. Build a top-level procedure from standard steps, each covering a group of work such as torquing, sealing, and inspecting.
  2. Release the standard steps whose instructions are complete so technicians can start them.
  3. For a standard step whose instructions are still in progress, put its run step on hold. The hold blocks work until the instructions are ready.
  4. When the instructions are finalized, release the updated standard step and take the run step off hold. The run picks up the latest released version automatically.

​
mBOM structure

  • Build subassemblies in their own procedures. Tie a procedure to a single parent assembly and give each subassembly its own procedure. A procedure tied to a lower-level subassembly can’t also be tied to the parent, which avoids circular loops in the dependency graph.
  • Keep the mBOM to real inventory. Model only physical parts that can be installed, uninstalled, or held in inventory, rather than manufacturing states. This keeps parallelization and uninstall behavior predictable and brings your eBOM closer to your mBOM.