The EDGEBIC Visual Routing Editor Explained: Draw the Process
User Solutions TeamEDGEBIC by User Solutions includes a visual routing editor that lets you build a product's routing as a diagram of connected operation nodes, drawing the sequence as links and configuring alternates and parallel work on each node, so a complex process reads as a picture instead of a puzzle of grid rows. A routing is a flow, and flows are easier to reason about as diagrams than as tables once they stop being straight lines. The visual editor is where a planner draws the process the way they think about it.
This is an authoring surface over the same routing the scheduler runs, the bill of routing. The diagram is not a separate artifact to keep in sync; it is a different pen for writing the one routing definition.
Nodes Are Steps, Links Are Sequence
The editor's grammar is simple. Each operation is a node you place on the canvas. Each link you draw between two nodes sets their order: connect step 10 to step 20 and you have said 20 follows 10. Build the whole process by placing nodes and drawing the connections, and the routing's sequence is the shape on the screen.
Those links are not decorative. They are exactly what the scheduler reads to order operations, and exactly what draws the dependency arrows on the Gantt view. What you connect in the editor is what the engine plans against and what the timeline shows, which is why the picture stays honest.
Two Ways to Author, One Routing
EDGEBIC lets you build a routing as a grid of rows or as a diagram, and both edit the same underlying data. This is a deliberate choice rather than a redundancy, because the two shine in different places.
The grid is fast for simple linear routings and for bulk edits: type the steps, set the numbers, done. The diagram earns its keep the moment a routing has branches, alternates, or parallel paths, where rows force you to reconstruct the shape from sequence numbers and cross-references in your head. Many planners live in the grid for routine work and reach for the diagram when a process gets complicated. For the step-by-step of building a routing either way, see how to build a routing.
Where a Picture Beats Rows
The concrete case for the diagram is the routing that is not a straight line. Three situations make the visual form clearly better.
A branch, such as an inspection that sends good parts forward and rework parts back, is a fork you can see in the diagram and a tangle of cross-referenced rows in the grid. An alternate, where a step can run on either of two work centers, is a choice you configure on one node visually rather than tracking across columns. And parallel work, where two operations run at once and rejoin, is a pair of paths that split and merge on the canvas, where the grid can only imply the relationship through settings. For the mechanics of alternates and parallel work, see how to configure parallel and alternate work centers.
In each case the diagram makes a specific class of mistake visible: a step pointing at the wrong successor, a parallel branch that never rejoins, an alternate configured on the wrong node. Those errors hide in rows and jump out of a picture.
Configuring the Node
A node is not just a box in a sequence; it carries the operation's real settings. The same timing that governs scheduling, the setup time, the run time, the queue and transit times, and the alternate or parallel configuration, lives on the node. So the diagram is not a sketch you later fill in elsewhere; drawing and configuring happen in one place, and saving the diagram saves the routing complete.
That completeness is the key reassurance. There is no export step, no translation from picture to plan, and no risk of the diagram and the real routing drifting apart, because they are the same object viewed through the editor.
Where It Fits
The visual editor sits in the master-data layer, alongside the grid form of the routing and the products the routings belong to. You author a product's process here, and the scheduler consumes it on every run. When a routing changes mid-flight, EDGEBIC preserves the version a job was scheduled against through frozen routings, so editing the diagram for future jobs does not disturb work already in progress.
For the whole system the editor feeds, the complete EDGEBIC guide is the map.
The Point of Drawing the Process
A routing is a manufacturing process, and processes have shape, forks, joins, choices, parallel paths, that a table flattens and a diagram preserves. Letting a planner author the routing as the diagram they already picture in their head reduces the translation between how the process works and how the software records it, and it makes the errors that matter visible. That is the value of a visual editor: not prettier data entry, but a truer representation of the thing you are actually describing.
Want to draw one of your trickier routings and watch it schedule? Bring an export to a demo and we will build it on the canvas.
It is a graphical editor for building a product's routing as a diagram of connected operation nodes rather than a list of rows. You place each step, draw the links that set the sequence, and configure alternates and parallel work centers on the node, so the shape of the process, including branches and parallel paths, reads as a picture. It edits the same routing the scheduler uses; the diagram is a different way to author it, not a different thing.
EDGEBIC offers both a grid and a diagram for authoring routings, and they edit the same underlying data. The grid is fast for simple linear routings and bulk edits; the diagram earns its place when a routing has branches, alternates, or parallel work, where a picture is far easier to reason about than rows. Many planners use the grid for routine work and the diagram when the process gets complicated.
Yes, that is its core job. The links you draw between nodes are the sequence: step 20 follows step 10 because you connected them. Those same links are what the scheduler reads to order operations and to build the dependency picture on the Gantt, so what you draw in the editor is exactly what the engine plans against.
Expert Q&A: Deep Dive
Q: When is the visual editor genuinely better than typing rows in a grid?
A: The moment a routing stops being a straight line. A five-step linear process is easy to read as rows and the grid is faster to type. But add an inspection that branches, or a step that can run on either of two work centers, or two operations that happen in parallel and rejoin, and the grid becomes a puzzle of sequence numbers and cross-references that you have to reconstruct in your head. The diagram shows those same relationships as what they are, forks and joins and alternates you can see, so mistakes like a step pointing at the wrong successor or a parallel branch that never rejoins become obvious instead of hidden. Use the grid for the simple many and the diagram for the complicated few, and you get both speed and clarity where each matters.
Q: If I build a routing in the diagram, is it the same routing the scheduler runs?
A: Yes, and this is the important reassurance. The visual editor is an authoring surface over the one routing definition, not a separate diagram that has to be kept in sync with a real routing somewhere else. The nodes are the operations, the links are the sequence, and the settings on each node are the same setup, run, queue, and alternate configuration the engine reads. When you save the diagram you have saved the routing, and the next schedule run plans against exactly what you drew. There is no export step, no translation, and no risk of the picture and the plan drifting apart.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
How an Open EDGEBIC Screen Notices Someone Else's Edit
On a shared database, a change made on one workstation reaches every other open screen within a few seconds, without anybody pressing anything. How the change signal works and why your selection survives it.
What Changes When EDGEBIC Moves to a Shared Database
Moving EDGEBIC from one workstation to a shared SQL Server changes three assumptions at once: who may overwrite whom, how an open screen stays current, and who may run the scheduler.
What the EDGEBIC Refresh Button Actually Does
The refresh button forces a full re-read from the database, which is not the same as closing a screen and reopening it. Why the distinction matters on a shared database, and when to press it.