Start a conversation
  1. ACRM Support
  2. ACRM - Articles
  3. Public Articles

CRM.web Shows “Unexpected” History (H0) Entries Under Generated Tables (AureaCRM 15.24)

Contents

Overview

In AureaCRM (reported on version 15.24), CRM.web may show History (H0) entries in a generated table record’s Related Data sublist that appear “wrong” to end users (for example, “there are 4 records in History table, which should be not there…”—later clarified as 3). Typically, no application error message is displayed.

This is expected behavior: CRM.web lists H0 entries using generic parent-link resolution. If the generated info area uses mappings or virtual/derived fields, a change can be logged against an underlying info area/record, yet still appear under the generated record in CRM.web.

Solution (How to Explain and Audit the H0 Entries)

What you may observe (verbatim symptom)

  • “there are 4 records in History table, which should be not there because those history records did not happened on that generated table” (sometimes reported as 3).

Cause (Expected behavior)

CRM.web displays History (H0) entries in the Related Data area based on generic parent links. History entries are not displayed solely because they were “created inside” the generated table UI.

This is especially relevant when the generated info area uses:

  • Field mappings, and/or
  • Virtual/derived fields

In these cases, a change can be recorded against an underlying info area/record, but the H0 line can still appear under the generated record in CRM.web due to generic link resolution.

Resolution / Mitigation

There is no product fix for this scenario. The practical approach is to confirm why the entries appear and to produce audit evidence showing exactly what created each H0 entry.

1) Identify what triggered each History entry

For each unexpected H0 record, note:

  • H0 entry ID(s)
  • Field Number / Field Name (these indicate which field/action generated the History line)

This narrows down whether the entry came from a mapped/virtual field or another indirect update.

2) Check whether mappings / virtual fields are involved

In Maintenance, review the generated info area configuration:

  • Maintenance → Data Model → Info Area → Mappings (and any related configuration for virtual/derived fields)

If mappings exist, History can legitimately be created against the underlying info area while still being displayed under the generated record in CRM.web due to link resolution.

3) Use the supported audit method: generate an H0 XML report

Important constraint: History (H0) data is stored in BLOB format and cannot be inspected via normal SQL queries.

Generate an XML report for H0 from CRM.win and include (at minimum) these fields:

  • ID
  • Stat.No.
  • Date
  • Time
  • Rep ID
  • Rep
  • Windows User Name
  • Windows computer name
  • Version
  • Module
  • Field Number
  • Field Name
  • Old Value
  • New Value
  • Time Zone

Then filter the report to the specific unexpected H0 record IDs.

4) Communicate the findings to stakeholders

Use the XML report output to demonstrate:

  • Who made the change (Rep / Windows user)
  • When it happened (date/time/time zone)
  • What changed (field number/name; old/new values)
  • From where it originated (often inferred from mappings/virtual fields plus module/version context)

This helps address trust concerns by showing the History lines are traceable to specific changes and displayed via generic link resolution (not random entries).

Note: This behavior has been reviewed without identifying an engineering defect; it is handled as expected product behavior.

Validation (How to Confirm You’re Done)

  • Confirm the generated info area’s mapping/virtual-field configuration is understood and documented.
  • Confirm each unexpected H0 line is explained by the XML report evidence (who/when/what field/old value/new value).
  • Re-check CRM.web: the same H0 entries may still display (expected), but you can now justify why they display and what produced them.

Frequently Asked Questions

1. Is this a bug if History (H0) appears under the “wrong” generated table record in CRM.web?
Not necessarily. CRM.web shows H0 entries based on generic parent-link resolution. With mappings or virtual/derived fields, History can be recorded against an underlying record and still appear under the generated record’s Related Data area.
2. What “error message” should I look for?
This scenario typically has no application error message. The symptom is the visible presence of unexpected History rows, for example: “there are 4 records in History table, which should be not there…”
3. How do I figure out what created the unexpected History entries?
Capture the H0 entry’s Field Number / Field Name and generate an H0 XML report (filtered to the specific H0 IDs) including Date/Time, Rep, Windows user/computer, Version/Module, and Old/New values. This provides evidence of who/when/what created each entry.
4. Can I audit History (H0) directly in SQL?
No. H0 is stored in BLOB format and cannot be inspected via normal SQL queries. Use the supported XML report approach from CRM.win.
5. What configuration should I check if this happens?
Review the generated info area’s mappings and related configuration: Maintenance → Data Model → Info Area → Mappings (and any virtual/derived field setup). Mappings/virtual fields are a common reason History appears “unexpectedly” in CRM.web.
6. What if I already see many of these fields in the CRM.web sublist—do I still need the XML report?
Yes. The XML report is the supported export/audit artifact and is useful for sharing, filtering to specific H0 IDs, and providing formal evidence of who/when/what created the entries (especially for stakeholders who question reliability).
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted

Comments