Connecting Engines to Your Datastores

A binding is the mapping between an ERP engine and your data model. It is what allows the stock engine to work with a datastore you called Parts, and the time engine to work with one you called Jobs, without either engine knowing those names in advance.

Roles and slots

Each engine declares what it needs in abstract terms.

• A role is a table the engine needs — the item role, the header role, the line role, the project role.
• A slot is a column within that role — the code slot, the quantity slot, the date slot.

You fill in which of your datastores plays each role, and which of your columns fills each slot. From then on the engine asks for slots and never for columns, so it works identically whether your quantity column is called Qty, Quantity or Number_Of_Units.

Where to configure it

Bindings have their own screen in the Architect Panel, laid out as a matrix of roles and slots per engine. This is one of the few places the platform provides a bespoke screen rather than a plain datastore list, because a grid is genuinely the right shape for the job — you are filling in a table of correspondences, and seeing them all at once is what makes a gap obvious.

Constants as well as columns

A slot can be filled with a fixed value instead of a column. If every row in your system is the same warehouse, the warehouse slot can simply be that warehouse rather than a column you would have to add and populate identically on every record.

Bindings use names, not internal IDs

A binding refers to your table and column by name. This has one consequence worth knowing about: renaming a physical datastore or column breaks any binding that refers to it. If you rename something, revisit the bindings screen.

The alternative — referring to internal record IDs — would be worse. Those IDs are reassigned when the platform updates, and a binding that silently pointed at a different table after an update would, for a ledger, mean posting into the wrong company's books. Every other modern part of the platform that links to a table by configuration does the same thing for the same reason.

Validate before you rely on it

An incomplete binding produces an engine that appears to do nothing, in the same way a missing table rule does. Fill in every slot an engine asks for, save, and test one record end to end before configuring the next module.

Order of work

Bind before you configure. Almost every article in the rest of this section assumes the relevant binding is already in place, and most module problems that look mysterious turn out to be a slot left empty.