Dependency management, what kind of refresh?

Dependency management, what kind of refresh?


There seems to be two levels of refreshing dependencies in OutSystems and I feel at a loss when I try to talk about them without taking the time to explain the difference in actions.

The first type is mostly automatic, when you change something about how a module works without changing it's signature or interface. To pick up that change it seems you need to open the Add/Remove Dependencies window in outdated consumers (in v9, Manage Dependencies in v10) and then click OK and click Publish. Then the consumer picks up the changed code. I believe that republishing consumers when publishing into a new environment does the same thing. If I publish in the same environment without opening the Add/Remove Dependencies window and clicking OK it still doesn't pick up the change so it seems that opening the Dependencies window and clicking OK is doing some kind of reference refresh.

The second type requires a manual acknowledgement when you change the interface of a module. To pick up that change you do almost the same as the nearly automatic type, but you must also click the circular arrow refresh button to the right of the module name (or ) which gives you a chance to review the changes and then click OK. Once you publish that kind of change with your consuming module, OutSystems helps by enforcing that the producing module is already in the next environment or moves at the same time that you promote your consuming module to the next environment, for example from development to testing.

Is the first case not a type of reference refresh? What is it called?

I have trouble calling both of them a refresh when I discuss them with others because their scope of change, of dependency coupling, and need to potentially update all consumers or hotfix items is completely different and I have not been able to find them called differently in the documentation.

Hello Jacob,

For what I could infer of those two situations, the first happens when the changes in the producer does not impact the consumer. Like when you change something that the consumer is not using.

If you look in the application page, the consumer is marked outdated, because there is a new version of the producer, but when you open the references management, there is nothing to "refresh", because nothing you are using changed. 

It seems that in this case, you can "force" the consumer to use the new producer version by pressing "ok", but it seems to me that the behaviour in the consumer will not change at all, in this case.


Eduardo Jauch


Hi Jacob,

When you publish a consumer module (that is, an eSpace that references another one), it always uses the most recent version of the producer module (the eSpace that the referenced object like Action/Entity etc. lives in), regardless of whether you've refreshed anything in the Manage Dependencies... pop-up.

When the producer module has internal changes in referenced objects not visible to the consumer module, e.g. a change in the action flow of an Action or adding or renaming local variables etc., you only need to republish the consumer module to incorporate these change in the consumer.

When the producer module has changes in referenced objects that are visible to the consumer module, but that do not impact the functionality of the consumer module, e.g. when the description of an object has changed, an object was renamed, a parameter of an Action was renamed etc., you have an Outdated Reference, but you can still safely publish without it impacting the consumer modules functionality. If you open the Manage Dependencies... pop-up you'll see a blue refresh icon next to the producer modules to refresh these changes, so they are visible in the consumer module.

When the producer module has changes in referenced objects that are both visible to the consumer module, but that also impact the interface between the producer and consumer, e.g. when a parameter changes type, an Entity or Structure is changed, etc., you have an Incompatible Reference, and trying to publish the consumer will lead to a publishing error. In this case, you need to open the Manage Depencies... pop-up, and refresh the incompatible references (indicated by an orange icon). After that, you also have to change your logic in places where the refereshed object is used, especially if there are object parameters added/removed/changed or objects removed, but also when there are e.g. Attributes added to an Entity that you may need to fil when saving.


Hi Kilian,

The way you describe it makes perfect sense and seems the way it should be for outdated references, but not necessarily the way that I've experienced. It really seems that I've published my consumer for some other things, then went to test the new stuff including the changed producer feature and it was still working the old way but maybe I'm just misremembering in my order of operations or when the refresh icon was there. I'll watch more carefully next time.


Hello Eduardo,

This is what it seems like, that I'm needing to force the consumer to update it's information from the producer for the next publish by visiting the dependencies dialog and clicking OK, but perhaps I'm mixing a few steps together that makes it appear that way. Or maybe it's a product of our environment or something that the older OutSystems 9 did.

I'll try to watch more carefully to be sure of what it's doing.

Thank you,


Hello Jacob,

I did a small test and when there is no "broken reference", it seems you don't need to visit the reference manager.
Publishing the consumer is enough. It will in fact use the new version of the producer, like Kilian said.

Pressing OK in the window of the reference manager seems to "force" you to publish.



There are two situations in which you must be careful:

  1. If you change the producer of a producer, you first need to publish the producer, then your consumer, to make sure that the change is included (otherwise the producer isn't changed, only its producer).
  2. There's a bug in the Platform that sometimes causes the changes in an Extension not to be recognized, and they are not included.

Otherwise it should work as I detailed above.