Attributes
Attributes are the fields of a table. They set data types, enforce validation, and, through the business key, drive the versioning that protects your golden records.
What is an Attribute?
An Attribute is a field on a table. Each one has a name, a data type, and a set of validation rules. Together, a table's attributes define the shape of every record it can hold: they are the contract your data must honor before it can be trusted.
Getting there
The Attributes screen is reached from a table's row menu: Tables → ⋮ → Manage Attributes. The header shows a back arrow to the parent table list, plus the table name and its data model, so you always know what you are editing.
The attribute list
| Column | What it shows |
|---|---|
| Name & Description | The attribute name with a drag handle for reordering, the description, and a BK badge on business keys. |
| Type | A colored type pill: T Text, # Number, Z Integer, D Date, B Boolean, R Reference. |
| Rules | Active validation rules as badges: Key Required Unique. |
| Actions | A three-dot menu with Edit and Delete. |
Adding an attribute
Click + Add Attribute (or + Create First Attribute on an empty table). The dialog asks for a Name as users will see it, a Type from the six supported types below, and an optional Description, worth writing, since it is what guides non-technical users filling in the form later.
Supported data types
| Type | Use it for |
|---|---|
| Text | Names, codes, addresses, free-form notes. |
| Number | Decimal numbers — prices, ratios, percentages. |
| Integer | Whole numbers — counts, IDs, quantities. |
| Date | Dates without a time component. |
| Boolean | True/false flags — active, approved, taxable. |
| Reference | A link to another table's column, rendered as a dropdown. |
Reference attributes
Choosing Reference reveals two extra selectors: the Referenced Table (the source) and the Referenced Column (the field whose values populate the dropdown). When someone later creates or edits a record, the reference field behaves as a dropdown fed by the live golden records of the source table, so users can only ever pick values that are themselves approved.
Reference is also how you offer users a controlled list of values: model the list (statuses, segments, regions) as its own governed table and point the attribute at it. The dropdown then always reflects approved data.
Validation rules
The Create and Edit dialogs include a Validation Rules section with three checkboxes, each explained inline so you never have to leave the dialog to remember what it does.
| Rule | What it enforces |
|---|---|
| Business Key | Uniquely identifies records and drives versioning. Records sharing a business key are treated as versions of the same entity. Selecting it automatically also selects Required and Unique. |
| Required | The field must have a value on every record; saving fails if it is empty. |
| Unique | Every record must hold a distinct value for this attribute within the table. |
Editing, deleting, and reordering
The row menu lets you edit any property of an attribute, or delete it. Unlike most deletions in the platform, attribute deletion is permanent: the confirmation dialog warns that it cannot be undone and may affect existing records. Existing values stored in that field will be lost, so treat it with care.
To change the display order, use the drag handle (⋮⋮) on the left of any row. The order you set here is the order fields appear on the record creation and editing forms, a small detail that makes a real difference to data-entry speed.
Common questions
Can a table have more than one business key?
Yes. When several attributes are marked as business keys, their combined values identify the record, forming a composite key. Use this when no single field is unique on its own, such as Country plus Branch Code.
What happens to existing records if I add a Required attribute later?
Existing records keep their current values, but the table's completeness score will reflect the newly required field, and records missing it will need updating the next time they are edited. Plan schema changes early where you can.
Why is attribute deletion permanent when everything else is soft-deleted?
An attribute is schema, not data: removing it changes the shape of every record in the table, and the stored values for that field are dropped with it. That is why the platform asks for explicit confirmation. If in doubt, keep the attribute and simply stop using it.
How do I give users a controlled list of values?
Model the list as its own table (countries, cost centers, product categories), govern its records like any other master data, and create a Reference attribute pointing at it. The dropdown then always reflects the approved golden records of that table.