I started observing this behavior while working on an academy instance. There is an embedded data list and we have added a flow action for adding new items to that table. Now in this flow action, we configured a view. In this view, generally while we change a field on screen, refresh API is called and pyRefreshData data transform is run. It is running fine until a time, but suddenly it stopped. If I edit any field on the view now, there are no API calls in network tab. It is also happening in a different screen in another case type but is working fine in some other case types. Is there any specific condition for it to be called? Am I missing anything here? Please provide your inputs.
I think I just saw another post where @MarcCheong mentioned that, if we add a when condition on an embedded table, then it forces the screen to call refresh. I did it and it did the work for me. It made a refresh call. Now, there is another issue. I have added a when condition on āAllow adding new recordsā for the table. Now, that is not working. (I have added a when condition in such a way that if propertyA == ā123ā then show the Add button. When I enter the value 123 in propertyA, the refresh call is made, but the Add button does not appear) For the same thing, if I use custom condition, then the Add button is visible but there is no refresh call. So, only When conditions are forcing refresh call, but they are not working correctly.
the behavior you describe is usually tied to refresh settings + supported field types + rule interactions, not just āfield changeā by itself. In Constellation, the refresh request is expected to trigger when the configured form-refresh field changes, but there are instances where the call does not happen or stops happening because of view/rule conditions or platform behaviour.
The most common reasons are:
The field is not configured refresh trigger fields on the flow action
The field is an embedded page, complex field, or list, which is not always supported
If the view contains When rules, calculated fields or visibility/disabled/required logic, they might suppress or alter the refresh behaviour.
If it works in some screens but not others, that is usually related to a configuration difference.
Also, Pega does not refresh a data page more than once per interaction, so later edits in the same cycle may not generate another API call.
compare the working and non-working case types for differences in the trigger field type, refresh settings and view logic. If there are When rules involved, try replacing them with Custom Conditions and retest.
Thank you @RaviChandra for the response. I understood why custom conditions are working without a refresh call, because they are completely browser side. But somehow not able to understand why when conditions are not working. In the below example, I added a simple when condition on a view, based on the name property. When name is not null, the view should appear. I have opened network logs, I have a refresh call happened there. I see the tracer, I see that view is being rendered again and even the when condition became true. BUT in the portal, the embedded view is still not rendered. Anyhow, if I close/submit it once and reopen the view again, then it is evaluating correctly and showing the content.
First part of video contains me trying to open a modal dialogue, trying to enter a value in a property hoping that the below view becomes visible.
In this part, I submit the view and try to open same view again, now it renders the bottom part that is behind visibility condition.
@VVNagaSaiN When rules are evaluated server-side and tying it to form refresh in the same flow action/view can get out of sync. Even though the refresh call happens and the When evaluates to true on the server, because of ārace conditionā between the form refresh request and the separate refresh triggered for When rule, the view causes this unexpected UI behaviour.
Custom conditions work because they are evaluated entirely on the client side. so no extra DX API call is needed for visibility evaluation.
@RaviChandra Is it only an issue with my configuration somewhere OR does the visibility when conditions not work at all when we are editing a form? I donāt think that is the case. If I want to write a condition in such a way that I want the Add records button in a table to be hidden when user adds 5 records, I have to add a visibility when condition, as I cannot calculate count of page list using custom conditions, so, if the when rules are not evaluating when user is editing a form, I continue to see the button even after adding five records.
It is not that When conditions never work while editing a form. It is that in Constellation, server-side when rules can behave inconsistently during live form editing, especially when you expect immediate UI changes after the user adds/removes records.
Your use case is valid, you can configure separate conditions for CRUD actions and the add button can be hidden based on a condition once the limit is reached. Conceptually, yes, this should be possible. The problem is that if your logic depends on a server-side When rule evaluating during form editing!
The UI may not update reliably in the moment. Referring to the support article mentioned above you can find that there are limitations and race-condition issues around server-side When rules vs browser-side Custom Conditions in Constellation views, particularly when refresh behaviour is involved.
That is why you may still see the Add records button even after the 5th row has been added, even though your When rule logic is correct on the server.
For this scenario, I would be opinionated
If you need instant hide/show while the user is editing, prefer Custom Condition
If custom condition cannot directly calculate the Page List count in your setup, then do not rely on a raw When rule alone for live behavior. Instead, maintain a helper property like IsMaxRowsReached or CanAddMoreRows, update it through form refresh / post-processing / data transform when rows are added or removed and bind the UI to that simpler condition
Also make sure that the condition is configured specifically on the Add action, since Constellation supports separate conditions for add/edit/delete actions
@RaviChandra Thank you again for spending some time on this post. Yeah I have already used the work around of a helper property to achieve the requirement, but just curious about why the functionality is not working. Same thing, I did in another environment and another set of properties and guess what, its working absolutely perfect with when condition as well.
