Did the scoping of aggregates changed?

I get the feeling that the scoping of aggregates changed, I thought that when you create an aggregate in a flow, it is only usable after the creation, now I saw 2 occurrences where that didn't work that way, you can test it by creating an action (in a web application) create a aggregate create a loop behind it and create a aggregate after the loop, within the loop you can now reference the aggregate after the loop.That always will return null-values. Is this a change in 11 or did it always work like that? Or is this different in a mobile app?

Specially with the automatic naming of the aggregates this can lead to unexpected results .. 



It gets even worse, also the checking for scoping in if flows is now not there anymore :

I can ref the aggregate in the false part of the if ??? WTF ? This is really bad 

Hi Wim,

I did reproduce the same behaviour as you described in a Web Application, and I think  this is a bug, the if in the loop should not be possible! I already created a support case to OutSystems to look into this.

I tested it with version 11.0.506.0



Hi guys,

Queries have always been visible everywhere, after branching in flows and - yes - even before the flow reaches there. This is completely different from outputs of action calls. They indeed have an empty list in the cases.

It's weird, but it was designed so to simplify the Preparation actions.

Its not a preparaton, just an action, also in case of the if it's very strange, can't believe it always worked like that.

Hi Miguel,

It is weird for sure, I wasn't aware of it but can see the potential danger, it can lead to wrong coding. At least there should be some warning pointing you to a potential coding problem. I personally think this should not be possible.



Now also tested this in a mobile app, in a client action it does work with scope checking. The same for a server action, maybe I did mobile too much and expected the same behaviour in Web .. 

Wim, as i can check you can do it also in the v10.

I already saw some use of this pattern , in order to obtain some better performance.


In a preparation we set an aggregation  in a false if branch, and in a search screen action we make a refresh of it.

In preparation the aggregation only create the "output structure"  and in the search it fetch the data



I know, at the current project I am working on that is used also, but mainly because web actions of a screen cant be reused in another action on the screen, which is possible on mobile, which would be much better to prevent double code. I think because this is possible, refactoring code can be dangerous, if you move stuff around the compiler wont complain about problems that may be arising from moving assigns before a aggregate...  

Hi Wim,

Although I agree that it can cause some problems if you're not careful, it's always been this way, except for Mobile, where the underlying technology treats Aggregates the same as Actions. So yes, perhaps it's you spending too much time on Mobile :).

A good reason for this behaviour on Web are Preperations: they can run multiple times (in case you perform a Submit for example, or redirect to the same Screen), without losing the data. You could have a check on IsLoadingScreen() in an If-branch and skip the fetching of data (because it's still there) but then perform some initialization based on the data (either just fetched or fetched previously). On Mobile, you can't do this because there's no Preperation.

Ok I've done also more mobile then web to, but even though I passed professional exam time ago I was not aware that aggregates have a bigger scope in webb applications. Is this documented somewhere in OutSystems documentation? And also how to use this for like the patterns described in this thread? 

Still I think if it can cause problems that it would be nicer to be warned about it 

Maybe I should go back to Mobile ;-) maybe it's better to make the screen actions not to be too complicated, to prevent bugs happening. 

Hi Wim,

I'm not from Outsystem product's team but the above said behavior is because of the following reason

Any objects used in Preparation are basically internal page objects, so they can be shared/used in Screen Actions as well, which means that once you drag a component into the page, the object becomes a global object for that page and the object is initialized even before the preparation event triggers. 

As you might have already known "Outsystems doesn't support nullable types" and hence the initialization is happening even before the actual location in the workflow where you expect that to be initialized.

I wouldn't be too much bothered about this behavior, as I can handle it during my debug mode.

Certainly I'm not trying to defend outsystems here. I'm just trying to let you know the limitations and actual reason behind it.

Nice try but it doesn't just happen in preparation, also in normal screen actions, but I can handle it ... do that already a couple of years now (started with OS 4.2) , but having done a lot of mobile developing the last 3 or 4 years I got used to the right scoping there .. so back to reliable programming techniques in stead of trusting the OutSystems (pre)compiler :-). 

It's true it doesn't only happen with Aggregates and SQL in the Preperation, but it would be very confusing if they worked differently in the Preperation vs. any other Screen Action or Action. Anyway, as you started with 4.2, you must be familiar with this behaviour for a good 10 years or so, so nothing out of the ordinary :).