Batching Runs

Run batches

When working with many parts at once it can get repetitive to manually input information for runs that go through the same operation. The Batch function groups into batches where updates to the runs are synchronized to save time.

Run batches work by propagating changes made to one run to the others it is batched with. It doesn't matter which run you make changes to. The run's assigned user, due date and step progress will be synchronized.

ION will intelligently pick steps to synchronize based on step data - see the full list of rules below in Batch Propagation. This allows runs to be batched together even if they go through different processes in the past or future.

Creating a batch

Runs can be added to batches during creation using the "batch runs" checkbox, any time after creation using the Batch column in the runs table view, or in a run and selecting the batch button as seen below.

• During the Run Creation Process

• From the Runs Table view

• Within the Run itself from the run header

Viewing a Batch

Runs in a batch display a batch information banner at the top of the run header which can be clicked on to see information at a glance and then expanded to have more control over the batch.

When looking at the batch overview, clicking a different run will navigate you to that run.

Batch Propagation

🧩 1. Batch Matching Logic: Structural Identity

Behavior

Batchable steps are determined by system-defined identities:

• Last redline is the same

• Standard Step ID is identical (for standard steps)

• Or, the origin step ID is the same (for procedure steps)

• Step must be in TODO status

What this means:

Rely on core structural traits to better identify batchable steps.

🔄 2. Batching Impacts Nested Steps and Enforces Parent-Child Hierarchy Matching

Behavior:

• The entire step hierarchy—including nested steps—must match for batching to occur.

• Nested steps to a depth of more than 1 will now also batch.

Impact:

This prevents partially batched workflows due to hidden structural differences and reinforces step-by-step alignment across runs.

📤 3. Data Shared Across Batches

More consistent batch-shared data:

• Redlines to existing steps

• Adding new steps

• Dependencies

• Check-in session data

• Status

• Scheduled start

• Scheduled end

• Assigned user

• Lead time

• Workcenter

• Field entries

• Datagrid entries

• Comments

• File Attachments

Takeaway:

The system now treats batches more like a living procedural container—including structural changes (like added steps or redlines), not just step updates. This means changes ripple through the batch more comprehensively.

🚧 4. Rules on Step Status and Batching

Behavior:

• You cannot un-batch a run if any of its steps are in a REDLINE status.

• Only steps in TODO status are eligible for batching.

• To reapply changes to completed steps via batching, users must reset to TODO, batch, then reapply changes.

Why this matters:

This protects data integrity by ensuring batches reflect only modifiable, aligned steps—and keeps post-execution changes deliberate and controlled.

🔗 5. Enforcement of Dependency Logic in Batches

Clear rule: A downstream step in any run can only begin when the equivalent upstream steps in ALL batched runs are complete.

Consequence:

As you may change one run that had an issue to ensure it got repaired before rejoining a batch, this ensures those repairs are completed in advance of that part rejoining the batch, as an example.

Completing a Batch

You can move all completed inventory within a batch when a batch is completed.

Adding and removing individual runs

If the data/process of a particular run have a need to diverge from other runs in the batch, the run can be removed from the batch and modified independently. Similarly, other runs can be added after batch creation too.

Click on the batch label and use the batch edit sidebar to add and remove individual runs.