I second this idea. We had to convert a lot of aggregates to Advanced Queries just to be able to page the results. It surprised me that this isn't possible with OutSystems

I voice my support for this as well. We had to switch to advanced queries to implement paging (using OFFSET and FETCH NEXT). The biggest downside to this is it appears that using these queries to page through results gives us extremely slow query times (probably because OS uses "sp_executesql" to run the query). Because of how slow the query runs it's not a very good solution at all. I would love to see something implemented by the OS team that is performant and easy to set up.

I support this idea, I want to avoid complex queries as much as possible. Especially when exposing data using webservices and or server actions.

Would be nice if there was an startIndex property on the query so you only need to set that one with the max records and it's done!

The offset for paging is sorely needed.

Still on the radar?

@Trevor Olsen, The SQL OFFSET/FETCH functions will rely very heavily on correct indexes as they need to internally build a list of all the records EACH TIME before it can work out which ones to skip. If you have performance issues check to ensure that all the fields from the order by and the where clause are all contained in a single index, that might improve your performance.

For example, if you want to use the same Aggregate that is paging on ReactWeb or Mobile as well as TraditionalWeb, consider using API.

In that case, it must be SQL.

This is very inefficient and can be a factor in hindering code reusability.

Hi Vasco,

We've recently introduced reactive web apps where you can indeed set the start index on screen aggregates. 

In any case we'll keep this idea on our radar so we can implement this in server aggregates also in the future.

Thanks,
Tiago Simões

This should be a "must have" in Outsystems. 

If, for example, do you want to encapsulate an aggregate, because sometimes is for a page with paggination, and others this aggregate is used to "export excel", you need use startindex property for page usage. If not, the only solution is to build an advance sql, loosing a lot time, and losing all the power of a lowcode tool.

I totally agree with Carlos Olías this should be standard in Outsystems...

What if you need to expose a REST API and need pagination?

You are forced to build an advanced SQL consuming a lot more time...

Hello everyone,

It would be very helpful. The example that Diogo gave is an excellent example of how the implementation of this idea would be very useful. 

Best regards,

Décio Miranda

Cmon OutSystems! Having this server side is a must. To allow standardization of queries across the factory without additional code or custom SQL.

That could be very useful!

Hi all,

I’m reviving this thread because I was genuinely surprised to learn that this feature is still not implemented.

From what I understand, the official best practices recommend using Aggregates instead of Advanced SQL whenever possible, for maintainability and performance optimization.

However, if you try to decouple the UI from the data layer (e.g., by exposing server actions inside Business Logic modules that encapsulate filtering, sorting, and pagination), you immediately hit a wall: Aggregates don’t support start index and there’s no way to page efficiently inside a Server Action without switching to Advanced SQL.

This creates a contradiction between best practices and real-world use cases.

It’s especially painful in two scenarios:

1. Exposing paged data via API
2. Enforcing access control to entities and modular boundaries

In these cases, the only solution is to fall back on Advanced SQL — but that clearly conflicts with the platform’s own best practice recommendations.

I agree that this feels like a “must-have” feature in a platform aiming for scalable, secure, low-code enterprise architecture.

Thanks in advance!