Nested steps and standard steps

​

Best practices for nesting

• Use standard steps for reusable or critical instructions. Use a standard step when a set of instructions is likely to appear across many processes, or when updates to the instructions must be captured before execution. Choosing a standard step means any revision to that step reflects the latest instructions everywhere it’s used, whether in other procedures, standard steps, or runs.
• Group similar steps under a single parent step. Use one main parent step to group steps with shared intent. For example, to standardize torque instructions, nest all related steps under a single step named “Perform standard torque operation.” This consolidates related actions and improves clarity and dependency management.
• Create dependencies at a standard step’s root level. To build a structured dependency graph, nest standard steps within each other, then create and edit dependencies for a standard step only at its root level. For example, if the standard step “Seal hatch” includes another standard step, “Torque bolts,” edit the dependencies for “Torque bolts” within its own root procedure. This keeps dependency changes consistent everywhere “Torque bolts” is used.
• Release standard steps so improvements flow to dependent runs. Create and release standard steps to include them in procedures. Changes you make after initial runs reflect automatically across all not-yet-started dependent runs, which reduces redlining and merging. Place runs on hold until all necessary instructions are versioned correctly to avoid starting incomplete procedures. For example, if a run starts before the road-test procedure is finalized, the run pulls the latest version of the procedure automatically.
• Use the mBOM for subassemblies. When you set up an mBOM, connect a specific instance of a procedure to only one parent assembly to avoid circular loops in the dependency graph. Build subassemblies in their own procedures rather than one large procedure. A procedure tied to a lower-level subassembly can’t also be tied to the parent assembly.
• Avoid manufacturing states in the mBOM. Ensure all inventory is real inventory rather than a manufacturing state. A manufacturing state represents the state of the product rather than something physical that has been installed, uninstalled, or can exist in inventory. Avoiding manufacturing states prevents problems with parallelization and with uninstalling a process that already occurred, and it brings your eBOM closer to matching your mBOM.
• Keep nesting within the depth limit of 5. You can create up to five nested layers. As procedures become more deeply nested, assess complexity and clarity so the workflow stays manageable, and consider internal guidelines for how deep your organization nests steps. The limit safeguards procedure creation through the API, which without restrictions could create hundreds of layers of depth and affect system performance.

​

Example