Title

Enhance AL Query objects: Allow multiple sibling DataItems under the same parent DataItem while keeping a single root DataItem

Context / Problem

AL Query objects are a great way to access data efficiently while maximizing SQL Server pushdown. However, the current nested DataItem model is highly constrained: under a parent DataItem, developers cannot define multiple independent branches at the same level (the structure is essentially linear).

What this limits (or makes unnecessarily complex)

Many common scenarios require a “parent” record (e.g., document header, item card, vendor card) to be joined to multiple related tables independently at the same level, for example:

• Document Header
• Lines (Inner/Left Join)
• Approval Entries (Left Join)
• Shipment/Receipt Lines (Left Join)
• Reference/lookup tables (Left Join)
• 
  

Today, similar outcomes can often be achieved using multiple queries and merging results in AL, temporary tables, or other architectures that are more complex than necessary. So this is not strictly “impossible” today, but rather a modeling and design limitation that negatively impacts query readability, maintainability (duplicated filters and reconstructed logic), and the ability to design a query as a clear, visual join structure.

Proposal

1. Keep the current rule: a Query should still have a single top-level (root) DataItem.
2. Under that root DataItem (and under any parent DataItem), allow multiple child DataItems at the same level (siblings), each with its own:

• JoinType (Left/Inner, and Right if applicable)
• DataItemLink / join criteria to the parent
• Filters / DataItemTableView

Conceptual example:

• Sales Header (single root)
• Sales Line (Inner Join)
• Approval Entry (Left Join)
• Warehouse Shipment Line (Left Join)
• 
  

Expected benefits

• More visual, expressive multi-branch query architecture
• Less AL plumbing (less manual merging / fewer temporary tables)
• Improved maintainability (centralized structure and filtering)
• Preserves the Query object’s SQL pushdown intent

Important note

The main objective is not to enable something that is completely impossible otherwise, but to modernize the Query design experience: make query structures more expressive, maintainable, and closer to how developers naturally model joins, while still keeping a single root DataItem.