Skip to main content
Closed

Request to update the search and list query

Related products:Data Modeling
  • June 25, 2026
  • 2 replies
  • 38 views

Hi Team,

It was observed that List and Search queries have some functional limitations which are handled explicitly by teams. Below are the expectations:

  • Search queries must support pagination, enabling users to retrieve results beyond the current 1000-record limit.

  • Pagination should include a cursor or offset mechanism, allowing seamless navigation through large datasets without data loss or duplication.

  • List queries must support case-insensitive filtering

  • Users need substring search over large datasets, which is not fully supported. Can we provide feature like "Contains" which will allow substring search.

Thanks,

Rahul

2 replies

Everton Colling
Expert ⭐️⭐️⭐️⭐️
Forum|alt.badge.img
  • Expert ⭐️⭐️⭐️⭐️
  • June 25, 2026

Hi ​@rkumar87!

Thank you for suggesting this product idea. We will follow the traction this idea gets in the community. You can expect updates on this post if we decide to include this in our future roadmap, or if we require more information.


  • Practitioner ⭐️⭐️⭐️
  • July 8, 2026

Hi ​@rkumar87,

  • Search queries are backed by an optimized search backend, that is optimized for more performant and feature rich search experience than offered by the core data modeling service. We are upgrading the Search product continuously, and would like to offer users the ability to retrieve a bit more results than the existing 1000 limit, but there are no current plans to allow users to exhaustively retrieve ALL matched results using Search. Will update this thread if we decide to revisit this.
  • If the pagination request is related to Search, than the previous response tackles it. If its related to the underlying data modeling service itself, it already provides a pagination mechanism.
  • Unfortunately we do not have any plans to support case-insensitive filtering outside of Search. This sort of filtering is not possible without custom indexes for the relevant properties in place, and we believe such use cases are better served through our Search API.
  • Similar to the previous query, Contains type of queries are better suited for a our Search service. We do not plan to support them in core data modeling end points.

Regards