Tables

A table holds records. It always lives inside one model, and its shape is defined by the attributes you create on it.

Think of a table as a sheet in a workbook, or a table in a database.

Structure

Field	Description	Required
Name	The name of the table	Yes
Description	Free text	No
Use this as a reference table	Whether identifier/display name are required and the table can be referenced by others (API name: code_generation, AUTO or MANUAL)	No (defaults to off / AUTO)
Identifier column name	Only shown when the reference table switch is on	Yes, when it is on (defaults to Code)
Display name column name	Only shown when the reference table switch is on	Yes, when it is on (defaults to Name)
Tags	Any number of tags	No

Each table receives a source_id (UUID) that identifies it permanently.

The built-in fields: identifier and display name

Every table has two fields that you can neither create nor delete: an identifier attribute and a display name attribute. By default they are named Code and Name, but when creating a reference table you can choose different names — for example ISOCode and CurrencyName. Standard tables start with Code and Name. You can rename either attribute later from Edit Attributes.

• Identifier — a short, stable business key, for example SEK or 1200.
• Display name — a readable label, for example Swedish krona.

They exist so that a record can be presented to a human as SEK - Swedish krona. This matters most when the table is used as a reference table.

The role is fixed once the table is created

Which attribute holds the identifier and which holds the display name is chosen when you create the table and cannot be moved to a different attribute afterward. If you need a different column to hold that role, create a new table. You can still rename the identifier or display name attribute itself at any time from Edit Attributes — renaming is unrelated to which attribute holds the role. See Identifiers for why the role itself is locked down.

Reference tables

In the app this is a single switch: Use this as a reference table. Behind the scenes it sets the table’s code generation to MANUAL (the technical name you may see in the API).

	Standard table (AUTO)	Reference table (MANUAL)
Identifier is supplied by	Grunddata	You
Identifier required on every record	No	Yes
Display name required on every record	No	Yes
Identifier / display name visible in forms and grids	No	Yes
Can be referenced by other tables	No	Yes
Typical use	Data and transactional tables	Lookups and reference lists

How to decide

Ask one question: will another table need to point at this one?

• Yes → turn on Use this as a reference table. Users type a meaningful identifier, and the table becomes selectable as a domain table.
• No → leave it off. Users are never bothered with an identifier they do not care about.

Decide before you load data

Switching a table to a reference table later changes what every user must supply from that point on, and existing records will not have a meaningful identifier. It is far cheaper to get this right up front.

Create a table

1. Go to Models and open the model the table belongs to. If you have no model yet, create one first.

2. Click Create Table.

3. Fill in the name and an optional description.

4. Decide whether this is a reference table. If it is, choose the names for the identifier and display name columns (defaults: Code and Name).

5. Add any tags, then click Create.

Start from a spreadsheet

Want to save time? Start tracking a new spreadsheet in the Excel plugin. Grunddata creates the table and its initial columns for you, then you can immediately push the worksheet rows into Grunddata.

Use clear, unique headers and choose the right datatype for each column before tracking the sheet. Grunddata creates the table, columns and Excel formulas together, so it can safely reject the whole structure before any rows are uploaded if something is not valid.

Table names are unique within a model

Another model may have its own Accounts table, but one model cannot contain two current tables with the same name. The same check applies when you rename a table.

You can also see every table across every model from the top-level Tables page — useful when you know the table name but not which model it is in.

The table overview

Opening a table gives you its overview page, which is the hub for everything about it:

• Attributes — the columns, with counts of required and domain attributes.
• Records — the data grid, with add, edit and delete.
• Views — the OData contracts built from this table.
• Recent commits — who changed what, and when.
• Edit Table — change name, description and tags.
• Delete Table — remove the table, when nothing references it.

Tip

Tables you have opened recently appear on the Dashboard, so you can get back to the ones you work with daily in one click.

Update a table

From the table overview click Edit Table, or use the pencil icon in a table listing. You can change the name, description and tags.

The role cannot be reassigned here

The edit dialog shows which columns currently hold the identifier and display name roles, but the role cannot be moved to a different attribute — this is fixed at creation. You can still rename the attribute that holds the role from Edit Attributes. See Identifiers.

Tip

Renaming a table is safe. Attributes, records and views all reference it by source_id. If a view exposes it over OData, the view name is what downstream consumers see, so their queries are unaffected too.

Delete a table

From the table overview click Delete Table, or use the trash icon in a table listing, and confirm.

Deletion can be blocked

A table can be deleted even when it contains records; those records remain in the database but are no longer accessible through the deleted table. Deletion is blocked while another table has a formula or domain attribute that references it, or while a view is connected to the table. Delete connected views and remove formula or domain references first.

Deleting a model soft-deletes all its tables and views together, while retaining the records. The confirmation shows how many tables and views will be affected and lists any external formula or domain-attribute references that must be removed before the model can be deleted.

Next

AttributesDefine the columns of your table.

Domain tablesTurn a table into a governed lookup.