Creating reliable record identifiers: Use a unique, stable row ID generated at creation for internal links.; Assign keys consistently across forms, imports and automations to avoid conflicts.; Retain business IDs like serial numbers for real-world recognition, not as primary keys.
Image: No-Code Business Guide

Data Modelling

Part of No-code data modelling

Defining a reliable record identifier

Choose a stable row key, keep it distinct from a business identifier and plan how imports and relationships use it.

Desk Data · · 3 min read

Choose a row identifier that is unique within its table, present at row creation and stable for the row's life. Use it to link to or update the row. Keep a separate business identifier when people or another system must recognise the real-world item the row represents.

Key Principles for Reliable Record Identification

Unique per Table
Yes – must be distinct within its table
Present at Creation
Yes – must exist when the row is first created
Stable Over Time
Yes – should not change during the row’s life
Used for Relationships
Yes – essential for linking rows across tables
Not Based on Names
Strongly discouraged – names can be duplicated or changed

Separate row identity from business identity

An equipment app might store an internal Item ID for each row and a manufacturer's serial number in another field. The internal ID answers “which row should this link open?” The serial number may help staff recognise an existing item, but whether it is dependable depends on the equipment and its source. A person's name is a weak row key because names can be shared or changed.

Write down the purpose of each identifier. Is it for links inside the app, matching a later import, or a reference staff can read aloud? One field need not serve all three. A readable label may change while the row key stays put.

Row Identifier vs Business Identifier: Key Differences

  • PurposeInternal linking and referencing within the app; stable for relationships and updates.
  • StabilityMust remain unchanged throughout the row’s lifetime.
  • UniquenessMust be unique within the table; cannot rely on shared or changeable values like names.
  • User ReadabilityNot required; may be system-generated (e.g., GUID, auto-incremented ID).
  • Business Identifier ExampleManufacturer serial number, ABN, GST number, or a staff-readable code.
  • Use CaseFor recognition by people or external systems; may change if business context evolves.

Choose who assigns the key

Decide which creation route assigns the key and whether forms, imports and automations follow a consistent rule. A row key must remain constant, and worksheet row numbers are unreliable because they can change when rows move or are deleted.

If the app generates an ID automatically, confirm how the data source enforces uniqueness rather than assuming a generated value cannot collide.

Dataverse identifies rows with GUIDs and offers alternate keys made from one or more table column values for integration.

Each Dataverse alternate key has a unique name, and its columns should hold values that do not change. Creating one also creates supporting indexes. Use an alternate key when an external system cannot store the row's GUID and the chosen columns form a unique combination that remains stable.

Plan for imports and key changes

For existing rows, keep a mapping from an old identifier to the new row key. If another system supplies a stable business identifier, retain its value and source. Decide whether a later import should create a row, update a matched row or stop for review when its matching value is missing. Do not silently update a row on a name match alone.

Avoid editing a key already used by relationships. A reference column may hold the referenced row's key value, so replacing that key requires checking and reconciling existing links. Plan any replacement against the configured app and reconcile affected links. A shorter user-facing code can remain a separate field.

Use fictional cases to check the rule: two identical names, a corrected name, a missing business number and an existing item arriving through an import. State which case should create a row, match a row or need review, then check the intended route in the actual app before rollout.

Planning Reliable Record Identifiers in No-Code Apps

  1. Define the purpose of each identifierSeparate internal row keys from readable business identifiers used by staff or external systems.
  2. Choose who assigns the keyEnsure forms, imports, and automations follow consistent rules; avoid relying on worksheet row numbers.
  3. Enforce uniqueness at sourceConfirm data sources (e.g., Dataverse) enforce uniqueness for generated keys, especially alternate keys.
  4. Map old identifiers to new keysMaintain a mapping table for existing records when changing keys during migration or updates.
  5. Test with fictional casesSimulate scenarios like duplicate names, missing business numbers, or corrected data to validate import logic.

More from Data Modelling