To understand this, you have to know that each time you access the RGM (Recipegroup Manager), you are working with a copy of the RGM data.
So every screen that is opened in the Service Engine, has it's own copy of the RGM data. Also each instance of the RGM in the programming interface is it's own copy of the data. Until something is saved, either explicitly or automatically, the changes made are only available to the local copy.
When you save a change, this is stored in the RGM data, either locally or on the server, an then distributed to the standby server. This however does not affect the current instances (copies) of the RGM data that are open in screens or are instantiated in the programming interface.
When something is changed in one screen, it is necessary to reopen the other screen to see the changed data. Note that on reopening the screen without saving the changes, the local copy is rejected and a new copy from the RGM data is used.
This also means that if something is changed and saved in the programming interface (having it's own copy of the RGM data) it is necessary to reopen the screen to see these changes. Or in the programming interface, to re-instantiate the RGM object, to work with an updated copy.
Note, that if you change and save a recipe, only the recipe is saved, and not complete copy of the RGM data.
However, if you change e.g. a recipe value in one screen, and save the change, while the recipe is also open in another screen, and you change another recipe value in this other screen, the previous change is overwritten. The last copy that is saved has the priority. This is true for local editing with two screens and for local editing with e.g. a screen and an instance of the RGM data in the programming interface. But also for editing with a screen, and editing via a RGM function.
This same principle is also true for the RGM in the network, when two clients open and edit the same recipe simultaneously. The last recipe that is saved, has the priority and overwrites any prior changes.