I've built an experience in which a selection made on the first map causes the layers in the second map to be filtered.
In general it works well, but in some cases the second map fails to re-render all the layers after their filters have been applied, so the graphics for records that have been "filtered out" can tend to remain visible on one or two of the layers, until the map is zoomed in or out or otherwise forced to redraw.
It seems like the sensible thing would be for all filtering and selection logic to be applied before zooming and panning actions, with a final redraw of everything just for good measure. I get the feeling that the order of execution is to some degree influenced by the order in which the actions are listed, but I'm not sure whether it's simple as the first item in the list being executed first (or last), or if there is already some kind of effort in place to reprioritise the different kinds of actions. So I feel like I'm just winging it to get it to work!
I switched one of the misbehaving layers from a "framework-based filter" to a "map-based filter", and added a selection action on the other one, and have played around with the order in which the map actions are listed. And thankfully that seems to force enough redraws to end up with a map that is rendered correctly.
Is this a known "vulnerability" of experience builder, and if so are there established practices for handling it (e.g. a recommended order in which to list the different actions, so that they "agree" with the map rendering)? If not, could it please be attended to fairly urgently, as it could threaten to make such apps unpublishable!
