Support relating a LogEntry to multiple records via a junction object, preserving backward compatibility

[francescopitzalis]

New Feature Summary

I’d like NebulaLogger to support relating a single LogEntry to multiple relevant records (e.g., Account, Opportunity, Case, or custom records) without duplicating the log entry or its payload. This is critical for large/bulk operations (such as HTTP calls to external systems with bulk APIs) where one transaction may impact many related records and duplicating logs is not feasible due to data volume.

Motivation

• External APIs often support bulk requests; all involved records should reference the single request log.
• Log payloads (e.g., large HTTP request/response bodies) can be too large to duplicate for each record.
• Salesforce best practices recommend bulkifying operations, and the logging system should align with this practice.
• Viewing relevant logs from a record page (and vice versa) is a critical part of operational observability and support.

Proposed Solution

• Preserve the existing LogEntry__c.RecordId__c field for backward compatibility/cases where only one record is related.
• Introduce a new custom object, e.g. LogEntryRelation__c (or similar), with fields:
  • Master-Detail to LogEntry__c
  • Text(18) RecordId__c for the related record (optionally RecordSObjectType__c for filtering/display)
• Update the Related Log Entries LWC and its Apex controller to:
  • Query both log entries directly related by LogEntry__c.RecordId__c and via the new junction object to the current record
  • Show a unified, de-duplicated list on the record page
• Update/log APIs and builders to allow (optionally) relating a log entry to multiple records via the junction object, without breaking existing single-record APIs (setRecordId). Proposed: add addRelatedRecordId(Id) and setRelatedRecordIds(Set<Id>) to the existing log entry builder. Platform Event normalization should also support this.
• Ensure logs remain purgable/auditable/retained consistently (Master-Detail recommended for cascading deletes on relation rows).

Example Scenario

• A bulk HTTP POST/PUT request affects 500 records. One LogEntry__c records the request/response. 500 LogEntryRelation__c rows relate the log entry to the 500 records. Each record page shows the log entry in its log list; the log entry lists its related records.
• Legacy code logging to one record remains fully supported.

Acceptance Criteria

1. New junction object introduced and deployed (with Master-Detail to LogEntry__c, Text(18) for related record Id, optional SObjectType field, unique constraint on pair).
2. New (optional) builder API to relate many records in Apex/Flow.
3. Existing builder and platform event APIs are unchanged and backward compatible.
4. LWC related-list component aggregates both direct (RecordId__c) and indirect (junction) relationships.
5. Documentation updated (Apex, Flow, UI usage).
6. Logging, reporting, and purging continue to work as today.

---

If you have thoughts on implementation pattern or want to discuss risk areas (batching, async, platform event payload), please comment below. Happy to help refine.