Anna Amina Isengwe Copilot summary

Today, DV QnA (Dataverse QnA) and Copilot in Dynamics 365 often return a list of email records with brief, generic summaries, rather than extracting concrete insights from the email bodies that users can act on such as next steps, commitments, blockers, dates, owners, risks, and decisions. This gap is most visible on account timelines where organizations track emails. Users expect Copilot to synthesize the conversation history and surface actionable guidance; instead, they receive record lists with minimal value. This pattern has been reported by customers in recent cases handled by our team (e.g., “Copilot not summarizing tracked emails in Dynamics 365 Sales” and “Record Summary Activity” concerns) where Copilot can see the emails but does not produce meaningful, task‑level output.

Problem Statement

When configuring multi-level hierarchies (e.g., Account-to-Account via custom connection tables), the platform currently builds a single QueryExpression that enumerates all possible related tables. In environments with many custom tables referencing Account, this results in more than 100 filter conditions, causing the configuration to fail due to the hard QueryExpression limit.

This behavior effectively blocks use of the hierarchy feature for common enterprise scenarios, even though customers accept the 100-entity limit itself.

Current Limitation

• The 100-condition limit is enforced for performance reasons (by design).
• The hierarchy configuration issues stem from how the query is constructed, not from the customer’s intent to exceed supported limits.
• 
  

Customer Expectation / Feedback

Customers are not asking to remove or increase the 100 limit

They expect the platform to:

• Load the first batch (e.g., 100 entities), and
• Use paging or incremental loading instead of issuing a single, unpaged query.

This would allow the feature to remain performant while still being usable in real-world schemas.

Proposed Enhancement

• Introduce paging or incremental loading when resolving hierarchy-related queries.
• Avoid generating a single QueryExpression with >100 filter conditions.
• Optionally cap each page to existing limits while allowing traversal across pages.

Business Impact

• Enables hierarchy features to function in complex but valid enterprise environments.
• Reduces support escalations where behavior is technically “by design” but functionally blocking.
• Improves customer perception of scalability and robustness without changing core limits