dataverse_retrieve_record_change_history

Retrieve the full audit change history for a specific record.

Calls the unbound RetrieveRecordChangeHistory function, which returns the same AuditDetailCollection container as its column-scoped sibling dataverse_get_attribute_change_history — the entries sit TWO levels down (AuditDetailCollection -> AuditDetails), not one.

AN HTTP 200 IS NOT PROOF OF ANYTHING, AND ON A 404 READ THE ERROR CODE. Live- confirmed on this function, and the earlier note that auditing being off produces an HTTP error was WRONG:

• auditing disabled at organization/table level returns HTTP 200 carrying the audit-configuration rows described below and ZERO genuine changes — not an error, and no error message to read;

• MOST tables do NOT validate that the target record exists: a well-formed but NONEXISTENT record id with the CORRECT plural entity set returns HTTP 200 with zero genuine changes (12 of 15 entity sets swept on one org behaved this way, 'accounts' among them). An empty answer is therefore never evidence that the record is there, or that it never changed;

• a 404 is NOT automatically a naming mistake — the error CODE decides. [0x80060888] "Resource not found for the segment ''" NAMES the bad segment: the entity set is wrong (typically the singular slipped in for the plural) or that table is not provisioned on this org, so fix the name with dataverse_get_entity_sets rather than hunt a deleted row. [0x80048d02] has been seen instead from a CORRECT plural entity set ('audits') and there means what it says — the row really is absent. So some entity sets DO validate the target. One org and 15 entity sets were swept, so treat neither group as a complete list and read the code that actually came back. Use dataverse_get_attribute_change_history when the question is about one column; it additionally diagnoses which level auditing is switched off at.

NOT EVERY ENTRY IS A RESULT. Dataverse MAY add org-level audit-CONFIGURATION rows (records of auditing itself being switched on or off) to a response. They arrive when an audit-configuration change falls inside the TARGET RECORD'S history window, so their presence and count VARY BY TARGET — a record created after the last such change gets none, while older records on the same org got four each, live-measured. audit_configuration_events_count: 0 is a normal, expected answer. They are identified by their SHAPE — no @odata.type, AuditRecord and nothing else, and an all-zero AuditRecord._objectid_value — never by their position, which is not a contract. They are split out into audit_configuration_events (with audit_configuration_events_count) and are NOT counted: audit_details, count and has_more cover this record's own changes only.

ENTRIES ARE POLYMORPHIC — read each one's @odata.type, and detail_types counts the values present on the returned page. A RECORD-scoped call spans everything that happened to the record, so expect a wider mix than a column-scoped one: AttributeAuditDetail (OldValue/NewValue per changed field), RelationshipAuditDetail, ShareAuditDetail (live-confirmed here), RolePrivilegeAuditDetail and UserAccessAuditDetail are all documented subtypes. Every subtype carries an AuditRecord navigation property (who, when, what operation). An entry with an UNRECOGNIZED @odata.type is reported as a change, never quietly dropped, and unclassified_typeless_count reports how many entries carrying NO @odata.type were kept as changes because they did not match the configuration shape — it is 0 on every response observed so far, and a non-zero value means this tool met an entry it could not name rather than that anything was lost.

RESPONSE SHAPE IS CHECKED, NOT ASSUMED. If the AuditDetailCollection container is absent or is not a list of entries, the tool returns normalized: false with the raw body — a missing container is NOT reported as "no changes".

PagingInfo is not sent, so changes are trimmed client-side to top and has_more reports the server's MoreRecords OR anything the trim cut. total_record_count appears ONLY when Dataverse supplied a real count: it is live-confirmed to arrive as -1 here ("not counted"), and a negative value is suppressed rather than passed on as a number that reads like a count.

URL form: GET /api/data/v9.2/RetrieveRecordChangeHistory(Target=@p1) ?@p1={'@odata.id':'()'}