Dynamics 365 Business Central 2026 Wave 2 release (v29) silently introduces a new virtual table called Recent Record.
This table (defined in the System.Environment namespace) lists the records most recently accessed by the current user in the current company. Each row identifies one referenced record.
The list is always scoped to the current user and company and those dimensions are not exposed as fields. The table is read-only by design (you cannot insert or modify existing records) but records on it can also be deleted to clear the recent history.
The table lists the following references to the original table’s record on it:
- TableId (Integer) (PK1): points to the table id of the original record
- RecordSystemId (Guid) (PK2): points to the SystemId of the original record
- LastUsed (DateTime)
- Description (Text[2048])
For example, when you open a Customer Card page a record is logged as in the following image:
If you close and reopen the same record (customer 10000 in my example) the entry is updated with a new Last Used date value.
Records on this table are not logged if a record is managed via code. For example, if you run the Inventory Valuation report /that touches all Items), nothing will be logged here. The same applies if you execute an action that modifies a particular record via code: nothing will be logged. Only UI interactions are logged here.
This can be useful to track user’s activities within Business Central and maybe also for other scenario. Useful also for you? Let me know… 😅
There is an important missing information in this table: from where it was used.
And what does “used” mean? Does running the “Inventory Valuation”- report for all items mean that the user “used” all items?
LikeLike
No only records “touched” via UI are logged. Added a note in the post, thanks.
LikeLike
A sometimes annoying but also sometimes very useful feature of the old Windows- Client was that he stored the last used record of a page not only for the object but also or the the menu-entry from where it was called.
So you were able to have multiple “workpaths” f.e. one normal order processing in a normal Sales Order view and another in a specific view on Online Sales Orders which are processed by a different page. Because of the feature you were able to switch between these views without loosing the context of the other, because the current record was stored according to the menu- entry it was called from.
And i think the only useful usage case for this table is to implement exactly this.
On the other side are records shown by info boxes or similar which is not a case that should produce an entry here.
On my view this feature is a little bit underdone, because it should have been not a big effort to store also at minimum the page that read the record, if you do not have an ID of the menu entry (Stored View) that caused the read.
LikeLike