Suggested by Anna Amina Isengwe – New
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