From Record Lists to Lists


We’ve had recurrent feedback from our developer community that we should aim for a simpler definition of generic lists. For example, to create a list of integers you would need to create a structure that contained a single integer attribute.

This represented a relatively large change in the way we deal with lists, but since it had such a wide impact on your productivity, we decided that with OutSystems Platform 9, we would incrementally improve our type system. And we didn’t want to wait for a major version release to share such an awesome feature with you, so we continued to evolve it. As that evolution came to a natural cut-over point, we deprecated the “old” way of doing it.


  • Before - If you wanted to represent a list, you would use the Record List data type;
  • From - We added a new data type called List, which is more generic than Record Lists. From to you could opt between using the new List or the old Record List.
  • - We added a new editor that allows you to more easily define your Lists and Records. As this point, since the List type can represent the same data as a Record List, and more, we removed the Record List data type.


If you were used to working with Record Lists, worry not, things aren’t that different now. Let’s check how using Lists is different than Record Lists:


Create a List of Basic Types

From 9.0 onwards, you can create lists of integers, lists of text, or a list of any other basic type. And it’s as easy as with other programming languages.

To create a list of integers, create a new variable and:

  • Set its data type to ‘List’;
  • Choose ‘Integer’.

That’s simple right? And that wasn’t possible with Record Lists.

Create a List of a Single Compound Type

Creating a list of a single compound type like Entity or Structure, was already supported before 9.0.

With Record Lists

Until, if you wanted to create a list of users, you would create a new variable and:

  • Set its data type to ‘Record List’;
  • Set its ‘Record Definition’ to ‘User’.

With Lists

Now with the List data type, things haven’t changed much. To create a List of Users, you create a new variable and:

  • Set its data type to ‘List...’;
  • Choose ‘User’.

The awesome part is that now to access the user’s name, instead of writing Users.Current.User.Name, you can just write Users.Current.Name.

I’ll grant you that this doesn’t seem much for the User entity. But in situations where the names of your Entities, Structures, and Attributes are long, this will save you a few keystrokes and is easier to read.

Oh, and you’ll notice that we’ve also updated the defaults. So, if you name your variable ‘Users’, we automatically define it as being a List of Users.

Create a List of Multiple Compound Types

Sometimes, it’s also handy to define a list of multiple Entities and Structures.

Until, to define a list of users and cities you would create a new variable and:

  • Set its data type to ‘Record List’;
  • In the ‘Record Definition’ you would choose ‘Record Editor...’;
  • In the ‘Entities/Structures’, you would add User and City.

Starting on, you can define a List of Users and Cities. Create a new variable and:

  • Set its type to ‘List...’;
  • Since we want a list of several types grouped together, we need to use a ‘Record’ type to group the Users and Cities. So choose ‘Record...’;
  • We now have a List of Records, and need to define the type of records. So choose ‘User’ and ‘City’ as names.

Just like for Record Lists, to access the user name of this List, we can use Users.Current.User.Name

And since this approach is more generic, we can even define a List of Users and a Boolean, which we couldn’t define using Record Lists.

Not So Obvious Gotchas - Aggregates

When you’re fetching data using Aggregates, they’ll always return a List of Record (just like above). This is because your Aggregates can have calculated or aggregated columns, so they can’t return a list of integers or a list of Entity/Structure.

So if you want to return the result of an Aggregate that fetches users, you might be tempted to define the output parameter as a User List, when in fact you need to define it as a List of Record of User.

Or you can do it the simple way, choosing the suggestion OutSystems Platform gives you.


Useful Links

It's a good step forward. However, it was easy to get lost prior to this post.
"List type can represent the same data as a Record List, and more, we removed the Record List data type."

1) In regards to Outsystems integration studio and extensions - will outsystems also change from record list to list type?
2) How are record list and list related? Can we pass a list to recordlist (and vice versa)?
Hi Robert,

In Integration Studio you still use a Record and a Record List, the change to support List in Integration Studio is in the backlog but doesn't have a release date yet.

What happens when you have a Record or a Record List in Inegration Studio?
Let's say you have an extension as follows:

Parameter1 is of data type Record and Parameter2 Record List. Next you add a dependency to this extension and you create a couple of variables to use the action in the extension:

Parameter1 is shown as a CompoudType Record and Parameter2 is shown as CompoudType Record List. You can now define local variables using the extension structure. Local variable CompoundType is of data type CompoundType and local variable CompoundTypes is of data type CompoudType List. When you pass these local variables as inputs to the action an implict conversion is made.


You state an implicit conversion is made. However, we typically work with large data sets that we pass through extensions. Doesn't this conversion slows down things considerably?