Identifiers: source_id, Code and Name

Grunddata uses several identifiers, and mixing them up is the most common source of confusion. This page explains each one.

Quick reference

Identifier	Type	Stable?	Who sets it	What it identifies
source_id	UUID	Yes, forever	Grunddata	The logical object — a model, table, attribute, view or record
id	UUID	No	Grunddata	One physical version row
version	integer	No	Grunddata	Which revision of the object this is
Identifier (default name Code)	short text	Yes, but editable	You (reference table) or Grunddata (standard table)	A human-readable business key on a record
Display name (default name Name)	text	Editable	You	A human-readable label on a record

---

source_id — the identity that never changes

Every object in Grunddata gets a source_id: models, tables, attributes, views and records. It is a UUID assigned at creation and it never changes for the lifetime of the object.

It survives:

• Renaming the object.
• Editing any of its values.
• Deleting it (a soft delete keeps the source_id).

This is why source_id is what everything else refers to:

• A table stores model_source_id to say which model it belongs to.
• An attribute stores domain_table_source_id to say which lookup it points at.
• A record’s data stores the source_id of each referenced domain record.
• The OData SourceId field is the entity key.

This is why renames are free

Because references are by source_id, you can rename a currency from Euro to EURO and every account that references it updates instantly. Nothing is stored by name, so nothing breaks.

Where you will see it

• In the records grid, as the Source ID column.
• In the Excel plugin and Sheets add-on, in hidden helper columns. Do not delete or edit them — they are how the plugin knows which existing row you are updating.
• In OData, as the SourceId key field.
• In the web app URL when you open a table or view.

Never hand-edit a source_id

If you overwrite a source_id in a spreadsheet, the upload will either fail or be treated as a brand new row, orphaning the original. If you want a new row, add a new row and leave the identifier columns empty.

---

id and version — the history

Grunddata never updates a record in place. Saving a change appends a new row:

id	source_id	version	account_name	is_deleted
018f…a1	018f…77	1	Nominal amount	false
018f…b4	018f…77	2	Nominal amount (SEK)	false
018f…c9	018f…77	3	Nominal amount (SEK)	true

• source_id is the same in all three rows — it is the same account throughout.
• id differs per row — it identifies that one version.
• version counts up on every change.
• The current state of the record is simply its highest version.

Deleting is a soft delete: version 3 above is flagged is_deleted and the row stops appearing in listings, in the Excel download and in OData. The history remains.

Rule of thumb

Anywhere you need to point at “that account”, use source_id. id is an internal detail you only encounter when reading raw history.

---

Identifier and display name — the built-in human-readable fields

Every table has two fields that exist automatically and cannot be added, removed or reassigned to a different attribute afterward: an identifier attribute and a display name attribute. They exist so that a record can be recognised by a person.

Named when you create the table

When you create a table and switch on Use this as a reference table, you choose the names for these two columns — they default to Code and Name, but you can call them anything, for example ISOCode / CurrencyName. This is the only place to set them: the attribute editor has no option to make an existing attribute the identifier or display name of an already-created table, because records and downstream consumers may already depend on which column holds that role.

Renaming is still allowed

The role itself is fixed, but the attribute that holds it can still be renamed at any time from the attribute editor, the same way as any other attribute. Renaming only changes the column header users see — it does not move the role elsewhere.

What each is for

• Identifier — a short, stable business key. SEK, NORDEASE, 1200. It is what you type, search on, and filter by.
• Display name — a descriptive label. Swedish krona, Nordea Bank Abp, Nominal amount.

Together they form the label you see when picking a value from a lookup:

SEK - Swedish krona

How they are populated: reference table or not

This is controlled by the Use this as a reference table switch on the table (API name: code_generation, AUTO or MANUAL).

	Standard table	Reference table
Who supplies the identifier	Grunddata	You
Is the identifier required from the user	No — hidden	Yes
Is the display name required from the user	No	Yes
Can be used as a domain table	No	Yes
Shown in the records grid	No	Yes
Typical use	Transactional / data tables	Lookups and reference lists

With a standard table, Grunddata generates the identifier for you and users never interact with it. With a reference table, the identifier and display name fields appear in the record form, the Excel sheet and the Sheets sidebar, and both must be filled in.

A domain table must be a reference table

A lookup is only useful if the person choosing a value can read it. A standard table produces machine values that mean nothing to a human, so only reference tables can be selected as domain tables. See Domain tables.

Choose identifiers that will not need to change

The identifier is editable, and changing it does not break references — but it will change what downstream OData consumers filtering on it see. Pick short, meaningful, durable values: ISO codes, LEI codes, account numbers. Avoid embedding anything volatile such as a year or an owner’s initials.

---

Which identifier should I use?

1. Linking two tables together? source_id. This is automatic when you use a domain table attribute.

2. Writing an OData filter or a Power BI relationship? SourceId for joins, Code for human-readable filters.

3. Uploading a spreadsheet of updates? Leave the hidden identifier columns exactly as downloaded for existing rows, and empty for new rows.

4. Building a report someone will read? Code and Name.

5. Investigating history? source_id plus version.