How the Designer Shows Sub-Assembly Branches

On the EDGEBIC design canvas, a sub-assembly branch is a star-marked node feeding into the step that consumes it. That star is the whole tell. It means the component has a routing of its own, so it is not a part you merely list but a branch that explodes into real operations at schedule time. Follow its single arrow forward and you reach the merge point where the sub-assembly rejoins the main flow. EDGEBIC by User Solutions draws multi-level routings this way so that a product built from sub-assemblies reads as one connected picture rather than a stack of separate lists.

This post is about reading the branch: how the designer distinguishes a sub-assembly from a plain material, where the merge point is, and what the branch becomes once the job is scheduled. For the build-and-configure walkthrough, see sub-assemblies in the EDGEBIC designer; this one focuses on reading the picture. Both sit under the visual scheduling guide.

Two Kinds of Component, One Marker

The canvas holds two kinds of component node, and telling them apart is the first skill.

A material node is a component consumed at a step, with no routing of its own. It books no production time; the scheduler assigns it instantly and moves on. It is a plain product node with an arrow into a consuming step.

A sub-assembly node is a component that does have a routing of its own. Because it must be built, not merely consumed, the scheduler explodes it and schedules its steps as part of the parent job. The designer marks it with a star, and its tooltip identifies it as a sub-assembly that explodes at schedule time.

The distinction is not cosmetic. A material adds nothing to the plan; a sub-assembly adds all of its own operations. So the star is the single most important glyph on a multi-level routing: it is the difference between a part you list and a chain of work you have to fit into the schedule.

The Branch and the Merge Point

A sub-assembly branch has a recognizable shape. The star-marked node sits off the main line, and a single arrow leaves it and arrives at a step on the main path. That arrival node is the merge point: the operation that consumes the sub-assembly.

The classic example is a frame feeding final assembly. The frame node carries a star. Its arrow connects into the assembly step. Assembly is therefore a merge, a node with two arrows arriving: one from the main product's machined body and one from the finished frame. Read the arrows into assembly and you have the complete list of what must be ready before assembly can start, which is exactly what the scheduler uses to time the branch.

If the frame itself consumed a sub-assembly with its own routing, that would branch too, one level deeper, and explode recursively. Each level is timed so its output is ready when the level above needs it. On the canvas you keep the diagram flowing one way and the depth reads as position: the deeper the sub-assembly, the further upstream its node sits from the finished product.

Previewing the Branch Without Leaving

A sub-assembly node shows a star, but the star does not show the child routing's steps on the parent canvas. That is deliberate, because painting every level's steps onto one diagram would make a large product unreadable. Instead the designer keeps each level's structure with its own product, and gives you a way to peek.

In the data grid, the sub-assembly row carries a View Subs button that opens the child routing read-only. You can confirm what the frame's routing contains, say weld then paint, without switching away from the parent. To edit the child routing you open the component product's own BOR, because that is where the frame's steps live. The parent canvas shows that the frame is a sub-assembly and where it merges; the child's own routing shows how the frame is built.

What the Branch Becomes at Schedule Time

The payoff of the star arrives when the job schedules. A sub-assembly branch is not a diagram flourish; it becomes scheduled work.

Schedule a 100-unit parent order and EDGEBIC also plans 100 frames through the frame's own work centers, positioned upstream of the assembly merge and timed so the frames are ready when assembly starts. On the Gantt those frame operations appear as real bars on their machines' lanes, before the assembly bar. The branch you drew on the canvas is now capacity consumed on the floor. This is why reading the star matters operationally: it tells you the schedule will carry work you might not have expected if you had read the routing as a flat list, where a sub-assembly and a material look identical.

Two Numbers on the Sub-Assembly Node

A sub-assembly node carries two settings that shape how the branch schedules, and reading them tells you what the branch will cost the plan. The first is quantity: how many of the component go into one unit of the parent. Set it to one and a 100-unit parent order plans 100 sub-assemblies; set it to two and it plans 200. That number multiplies the branch's whole workload, so a small quantity on a heavy sub-assembly can still add real load upstream of the merge.

The second is lead time, in days, for a component that needs procurement time before its own steps can run. Where a sub-assembly is partly bought and partly built, the lead time reserves the days the branch needs before work begins, and the scheduler positions the branch accordingly so the finished component still arrives at the merge on time. Reading these two fields on the node tells you the branch's scale and its timing at a glance: how much work it adds, and how early it has to start to be ready when assembly needs it.

A Worked Example: Frame-S Feeding Widget-A

Acme Industries builds Widget-A, and its routing runs body machining, then assembly, then paint. Engineering decides the frame should be a proper sub-assembly, Frame-S, with its own routing: weld at 0.4 hours per unit, then paint at 0.1 hours per unit.

On the canvas, the planner drags Frame-S from the products list, connects it into the assembly step, and sets its quantity to one per Widget-A. Hovering Frame-S, the tooltip now shows the star and identifies it as a sub-assembly, because Frame-S has a routing of its own. Assembly is now visibly a merge: the machined body arrives, and the finished frame arrives.

The planner saves the standard routing. A new 100-unit Widget-A order now schedules the frames too: 100 units through weld and paint on Frame-S's work centers, timed to finish just as assembly needs them. On the Gantt, weld and paint bars for the frame appear upstream of the Widget-A assembly bar.

Then the planner checks an older job, JOB-2026-0101, scheduled before the change. Its frozen copy still shows the routing without Frame-S, exactly as it was when scheduled, so the job on the floor is undisturbed. To pull the frame into that job the planner would tick Use Global BOR on Reschedule for it specifically and reschedule. The standard changed; the running job did not, until asked. This preservation behavior is covered in how a frozen routing snapshot protects a running job.

Reading the Branch Is Reading the Real Plan

Manufacturers have built products from sub-assemblies forever, and the hard part has always been keeping the levels straight in your head. User Solutions has been drawing those levels on a screen since 1991, for shops and for names like GE and BAE Systems, because a routing that shows its branches is a routing you can trust. The star is a small mark that carries a large fact: this component is a chain of work, not a line item, and the schedule will treat it that way.

Find the stars on your routing and you have found the work hiding one level down. Bring a multi-level product to a demo and watch its branches explode onto the Gantt. Give US the one with sub-assemblies inside sub-assemblies.