How a product is defined, explained

Before anything can be sold, planned, or built, it has to be defined. Engineering is the layer where that definition lives, and Workcell models it as a small set of records that each answer one question: what you make, what goes into it, how it is made, and how all of that is allowed to change. This primer explains the model; the how-to docs cover the clicks.

The building blocks

1. What you make and buy (Items)

Everything starts with an item: the things you stock, buy, sell, or make. An item carries its name, its unit of measure, and whether you Make it or Buy it. Every other record in Engineering, and every sales line, purchase line, and work order downstream, points back to an item. Nothing exists until the item does.

2. What goes into it (BOM)

A made item needs a recipe. A BOM (bill of materials) lists the components and the quantity of each that goes into one unit of the finished item. Exactly one line is the Primary (the item the BOM produces); the rest are the components, co-products, by-products, or waste that come with making it. The BOM is the answer to "what is this built from."

3. How it is made (Processes and Routings)

Knowing the parts is not the same as knowing the steps. A routing is the ordered list of operations that turn those components into the finished item, each step tied to the resource that runs it and the time it takes. Rather than redescribing "weld" or "inspect" on every part, you define each operation once as a reusable process, and routing steps point to it. Processes are a shared library; the routing is where they are sequenced for a specific item.

4. How it changes safely (Revisions and change orders)

Definitions are not frozen, but they cannot be edited carelessly either. Items, BOMs, and routings are versioned: each moves from an editable Draft to a locked Released state, and the released version is the one Production reads. To change a released definition you do not edit it in place, you revise it into a new draft, then release that. When a change needs sign-off, a change order groups the affected items, routes them through approval, and on release promotes each new revision in one controlled step, leaving the prior one intact as a record of what was built before.

Why it is split into records, not one big form

Each record answers a different question and changes on its own schedule. An item's identity rarely changes, but its BOM might be revised as a supplier swaps a part, and its routing might be revised as the shop finds a faster sequence. Keeping them separate means a routing change does not disturb the BOM, a process refined once improves every routing that references it, and every revision carries its own history. Production reads the released BOM and routing to build the item; Accounting reads them to cost it. Because the definitions are versioned, you can always trace a finished unit back to the exact definition it was built from.

Ready to walk it? Start with Create an item, then Build a BOM and Create a routing.