Process Tree

The Process Tree is a database table (process) that defines the full hierarchy of every manufacturing process in WSi. It controls two things simultaneously:

1. Which processes are visible and selectable in the WSi UI.
2. Which work step type each process is grouped into at runtime — the category WSi uses to decide which toolbar buttons and menu commands are available.

What the table contains

Each row in the process table is one process. The columns are:

Column	Type	Description
identifier	string	Unique ID for the process (used as parent reference)
parentIdentifier	string	ID of the parent process; empty for root nodes
type	value from the process-type list	Which of the 73 available process types this row represents
name	string	Display name shown in dialogs
costCenter	string	Cost centre for cost allocation
priority	int	Priority used when automatically selecting between processes
active	bool	Process-level enable/disable. If false, the process is hidden from the UI entirely
childrenActive	bool	Sub-tree enable/disable. If false, this process and all its children are hidden
description	string	Optional description

A process is fully available only when both active = true AND childrenActive = true AND all its parent processes also have both flags true. If any ancestor has childrenActive = false, the entire sub-tree is hidden.

How the tree is built

WSi reads every row from the process table at startup and arranges them into the hierarchy shown in the process tree, using parentIdentifier to connect each process to its parent. A few rules keep that hierarchy consistent:

• No cycles. A process can never end up as its own ancestor.
• One parent only. Each process has at most one parent — it is a strict tree, not a network with multiple parents per row.
• Root processes have no type of their own. A process with an empty parentIdentifier (a top-level entry) must have type set to undefined.
• Child types must fit their parent. A process's type must be one WSi recognizes as a valid child of its parent's type — the valid parent-child pairings are fixed by the software, not configurable per row.

If any row breaks these rules, WSi logs an error at startup and refuses to open the database until the row is fixed.

How work step types become available

Each process type belongs to one of 11 work step types — broad manufacturing categories such as sheet cutting or joining (see the mapping table below). At startup, WSi scans the active part of the process tree and works out which of those 11 work step types are currently reachable. That result drives which toolbar buttons and menu commands appear.

A work step type counts as available when:

• At least one process of that type is active
• That process sits inside an active sub-tree — none of its ancestors have childrenActive = false
• The process's type maps to that work step type (see the mapping table below)

Process types and work step types

WSi defines 73 process types in total, but groups them into only 11 work step types for runtime purposes:

Work step type	Included process types
sheet	sheet
sheetCutting	laserSheetCutting, laserSheetCuttingN2, laserSheetCuttingO2, plasmaSheetCutting, waterJetSheetCutting
sheetBending	dieBending, sheetMetalFolding
tube	tube
tubeCutting	tubeCutting
joining	joining, assembling, forceFitting, joiningByWelding, joiningByBrazing, bonding, plus all welding sub-types
packaging	packaging
transform	coating, sprayPainting, powderCoating, hotDipGalvanizing, cathodicDipPainting, electroGalvanizing, anodizing, countersinking
userDefined	manufacturing, forming, bendForming, bendingWithoutTool, cutting, removalOperation, machining, milling, turning, drilling, threading, userDefinedMachining, mechanicalDeburring, automaticMechanicalDeburring, manualMechanicalDeburring, cleaning, slideGrinding, tapping, sheetTapping, transport, etc.
userDefinedBase	externalPart, userDefinedTube, userDefinedBaseType
undefined	undefined, semiManufactured, all intermediate/abstract parent types

Activating and deactivating processes

To hide a process from users without deleting it from the database:

1. Open Settings → Database (Database Management dialog).
2. Find the process table.
3. Set active = false for the process you want to hide. Or set childrenActive = false to hide an entire sub-tree.

To restore, set both flags back to true.

WARNING

Setting childrenActive = false on a parent process hides all its children, including processes several levels deep. Use it to disable entire manufacturing categories at once.

TIP

Deactivating a parent and then reactivating it restores all children to their previous state — the flag is per-row, not propagated downward.

Adding a custom process

Custom processes can be added to the process table, but:

• The type must be one of the 73 existing process types (you cannot invent new types without a code change)
• The parentIdentifier must reference an existing process identifier
• The new row must pass all consistency checks described above

For User Defined processes that run custom scripts, use manufacturing or forming as the type. Both map to the userDefined work step type — a manual step that accepts arbitrary parameters.

For a full guide to writing custom cost and time formulas for such processes, see Custom Calculations.

Relationship with the database tables

Many child processes have dedicated parameter tables. For example:

• laserSheetCutting → laserSheetCuttingGas, laserSheetCuttingSpeed, etc.
• tubeCutting → Tube cutting - Process, tubeCuttingSpeed, etc.
• dieBending → bendDeduction, upperDie, lowerDie, etc.

When a process is active in the tree, its parameter tables are available for cost and time calculations. When deactivated, the parameter rows remain in the database but are not used.