Documentation for scope of web page variables

Documentation for scope of web page variables


Is there documentation of how page-level variables are scoped and stored in OS web pages?  For example, what happens to a local variable after the page is sent to the browser?  Is its value stored on the server or in viewstate?  What happens to aggregate query results from preparation after sending it to the browser?  Are only session variables saved on the server?

Thank you, there is a little information in this link above about the variable questions posed.  I'm hoping for substantially more clarity.

The documentation such as shows no information about this.

Are the following variable types persisted across web page refreshes?  For example, can you reference their value in a save action that is called when clicking a save button, which is typically done on a subsequent page submit?  I think the answers are below:

  • Input and local variable = Lost after first refresh, therefore no.
  • Widget record (form record like Form.Record or table list like ListRecords.List) = Persisted, therefore yes.
  • Session variable = Persisted, therefore yes.


Hi David,

Execution context will be stored in the view state, apart from Session variables that are stored in the database. That means that if you have (Ajax) Submits to a Screen Action, local variables will keep their values. If I'm not mistaken, something close to this:

  • Input & Local variables = stored in the viewstate
  • Outputs from Aggregates & Server Actions called in the preparation = stored in the viewstate if they're values are used in screen actions. What is actually stored in the viewstate depends on what is used in screen actions, so you may only see partial data in Preparation aggregates if you are debugging a Screen Action. Check Performance Top 10 Rules
  • Form/ListRecords/TableRecords local properties = stored in the viewstate
  • Session variables = stored in the database.

Hope this helps.


Hello David,

Since we do not have this level of detail covered in the OutSystems documentation, we would like to understand better why you are interested in the technical aspects of the web screen life cycle, namely the scope and persistence of variables. Do you have any specific concern or use case that you could share with us?

Thank you!

Hi Paulo.  One specific case is where I modified a page to go from a single step to a 3-step wizard.  After changing to a wizard, some of my variables became unavailable when the user finally got to the last step and clicked submit.  I was trying to understand which variables persisted during refreshes that occurred when the wizard step changes.

Hi David,

All screen variables (Screen Input Parameters/Screen Local Variables, outputs from Aggregates/Server Actions run in the Preparation, local properties for Forms/ListRecords/TableRecords) should keep their current values if you're using Submit/Ajax Submit and you end your Screen Actions with an End node (but not if you do server-side navigation with a Destination).

All session variables will keep their values between requests while there's a valid Session. Their values will be reset on Timeout or user Logout.

The online training materials do mention this though, on the Screen Lifecycle: Interaction video/slide deck (and Session Handling for Session Variables).

Hi David. All values that could subsequently be used in screen actions get stored in the viewstate (except for session variables and site properties).

For example, if you declare a variable on Step 1 of your wizard, let the user fill it with an input field, but then never actually use this variable for anything, then OutSystems reserves the right to remove that variable from the viewstate. If you do, however, use this variable (for example to store it on the database or send via a web service), then OutSystems will store the variable on the viewstate.

This decision will never change the behavior of your application for a user, but it might change the behaviour for a developer that is inspecting these variables in the debugger. If the variable is not stored in the viewstate, a developer might see its value as being "lost" after the first request, while debugging. Rest assured, that is an intentional optimization to make your applications run as fast as they can.

If you do believe this is generating incorrect behavior and is affecting the users of the application, then I suggest you to create a support case.

Leonardo and Jorge, those answers are very helpful.  I didn't find that video because it didn't show up when I was searching, so the video link is helpful.  The variables are discussed around the 5 minute mark.

Are the input variables also preserved during refreshes or are their values available only in the preparation?

Hello David,

The screen inputs are also available on all screen actions and preserved during AJAX refreshes.

hi all,

in Design time of a process, which ProposedSessionID is referred by the expression, either the ProposedSessionID n the Process1 or ProposedSessionID in the LaunchProcess1:



Hello Indra,

The expression is using the input ProposedSessionID of the process Process1, which is the input currently in the scope of the expression.

(In this particular situation, though, the value of this input could come from the input with the same name from the action LaunchProcess1, but this has to do with the way you can launch a process in OutSystems. You can learn more about this here.)

Hi Indra,

Paulo gave you the answer - it's the one from Process1.

A heads-up though... LaunchProcess1 is a very different thing. It's an action to start the execution of a process instance. You can use it in Processes but also in screen or server actions and you pass whatever value for the input:

Another thing, please start a new post next time, as your question is unrelated with original post!