Session variables: "List" data type

Hi all !

I'm building a new application ... for the first time I need a "List" session variable, but I have the warning "List data type should be avoided" ...

Is there a solution / alternative to that ? Do I have to use other kind of variable ?

Thanks !


Hi Luca,

Session variable for list is not commanded because An increase of the number of concurrent users in the application compounds the impact of using large session variables and it decreases application performance. 

Each web request loads the current session context. If the session variables are large text strings then each request will take longer to get the session variables from the session data model which can cause contention in the session data model further impacting otherapplication users. This is even more important when you use AJAX as it will increase the number of requests.

You have to be more specific why you need to assign list in session variable if the scope of list only to the page specific then you can use Local List variable and use action provided by outsystems to filter data and sort and other manipulation.

You can refer below link for best practices.



Hi Shoeb,

thanks for your reply.

My main goal is to "conserve" an array of values in some pages of my project.

The only way (that I discovered) to that is to use a Session variable.

Other any suggestion ?


Have you consider to create an entity  to keep those values.

Using a "GUID" as the identification for you session, create the records when you have the array (one record per value ) and use an aggregate to retrieve them when you need and delete them when the user signout. 

Hope this help



Also consider using Cache in the action or query that return the list, if those values don't change very frequently. That will improve performance.

If the values in the list are static and equal for each user, using a static entity might be a better approach.

Hi Luca,

You should store it in the database, this way you just have the cost of a query on that screen rather than having this weight on every request. This would become even more of an issue as the number of concurrent users grow.

You can see the full explanation, impact, solution and remarks here.