Every table in Business Central has eight fields you did not declare: SystemId, SystemCreatedAt, SystemCreatedBy, SystemModifiedAt, SystemModifiedBy, SystemRowVersion and the timestamp. They are what APIs, webhooks, delta reads, audit and Power BI incremental refresh run on. What each is, how to use them, and the two things people try to do with them that do not work.
Open any table in the symbol browser and below your fields are the system fields. They are maintained by the platform on every insert and modify, they are indexed, they are exposed by every API page, and they answer questions that extensions used to add fields for.
| Field | Type | What it is |
|---|---|---|
SystemId | Guid | A unique, stable identifier for the record, assigned on insert, never changed, unique across the tenant. The id in every API. |
SystemCreatedAt / SystemCreatedBy | DateTime / Guid (user SystemId) | When and by whom the record was inserted. |
SystemModifiedAt / SystemModifiedBy | DateTime / Guid | When and by whom it was last modified (any field, including by code). |
SystemRowVersion | BigInteger | A tenant-wide monotonically increasing version stamp updated on every write (version 25 and later). The reliable change-tracking column. |
timestamp | BigInteger | SQL's rowversion; older, per database, still used by the sync tooling. |
SystemId, not the "No.", because numbers can be renamed and GUIDs cannot. Record.GetBySystemId(Id) fetches it.SetFilter(SystemModifiedAt, '>%1', LastRun) gives "what changed since", for a nightly sync. Or SystemRowVersion > LastVersion, which is immune to clock issues and ordering problems and is what Microsoft's own Dataverse sync uses. Expose the field on your API page as lastModifiedDateTime as the standard APIs do.SystemCreatedAt for tables with no business date (retention post).SystemModifiedAt, so the dataset pulls a day of changes rather than the table.Email.AddRelation, document attachments and the record link table key on SystemId.You do not. The platform sets them, and Insert with a pre-set SystemId is allowed only when inserting with Insert(true, true) (the second parameter: insert with SystemId), which is for migrations and replication that must preserve identity across environments. SystemCreatedAt and the rest are read-only.
The Record Link table (links and notes on any record, the Links/Notes FactBoxes) keys on RecordId, which is the table ID plus primary key, not SystemId. A rename of the primary key moves them (the platform handles it for the standard rename); a copy-company does not. If you need a durable link from your table to another, store the SystemId in a Guid field with a TableRelation-less lookup, or use the RecordId type with the knowledge that it tracks renames.