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.
