Skip to main content
Some business objects have no standard equivalent: a weighing register, a sample log, a tooling reference list. When the information does not reduce to one more field on an existing record, you create a custom table: your own entity, with its records and its fields. A custom table is a first-class citizen. It has its records, its views, its filters, its change history, and it is exposed in the API with the same conventions as the standard entities. Your tools read and write it with no special handling.

​
What goes in it

The same field types as on a standard entity (text, number, boolean, date, choice list), plus links to Bonx entities: tying a weighing to a lot, a sample to an order, a tool to a site. That link is what makes the difference between a custom table and a spreadsheet on the side.

​
When a table is the right answer

  • The information has several occurrences for the same record (several weighings for one lot).
  • It has its own lifetime, independent of the record that produced it.
  • It carries several related pieces of information, not one isolated value.
Otherwise a custom field is enough and stays simpler to work with.
Custom tables are specific to your space: they exist only for you and are never affected by changes to the standard product.