The outer join feature recently described by
For detection RULES, while the community has shared a couple workarounds, they each come with tradeoffs:
in workaround 1. catch-all row in the datatable + reference list guardrail:
- scalability: limit of a max number of data tables allowed per rule
- longevity: reference lists to be EoL’ed in July 2027
- logic conflict: match section is required, turning single-event rules into multi. If the original rule was single-event and -because of enrichment- it is then applied match by any UUID / metadata.id, that would interfere with the alert throttling, making the throttling ineffective.
in workaround 2. ingest the table into the entity graph
same limitation of match section described above.
My goal is to perform "left outer joins" (enrichments) directly within detection rules - via Data Tables, ECG, or a similar mechanism, to allow us offload heavy enrichment tasks from the SOAR to the SIEM.
I have two specific questions for the Product Team regarding the roadmap:
- Outer Joins in Detections: Are there plans to bring the outer join functionality to the detection engine to support Data Table-based enrichment? If so, is the target release prioritized ahead of the July 2027 Reference List EoL?
- Custom UDM Fields in ECG: Is there a plan to allow Entity Context Graph (ECG) enrichments based on other (custom) UDM fields, rather than being limited to standard fields like user.email_addresses or hostname?
I’d love to hear if others are hitting these same or similar roadblocks.
Question
enrichments in detection rules - outer joins and ECG
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.


