Configuring URL Parameters to have specific layers enabled

Question

Is it possible to configure URL parameters for Experience Builder to have specific layers enabled upon loading?

I currently have a handful of themes for which one-off WebMaps and WebApps were put together to satisfy each specific theme. I also have an application that contains all of these themes within 1 WebMap, and 1 Experience Builder application. I would really like to get rid of these one-off applications in favor of URL Parameters that enable specific layers within the all-encompassing application.

In this way, I could have a 'zoning' link, but the link is just a URL Parameter that enables the zoning layer within the 'master' application.

I tried to check the URL Parameters guide, but I didn't see anything specific to this desire.

Any help or guidance is always much appreciated.

Update: It does appear that there is a 'Layer_Visibility' parameter, but it isn't explained very well in the URL parameters help document.

Update2: I got this sorted out by using the Share Widget and Layer Visibility enabled in Experience Builder. Enabling the layers that I wanted to be default on, and then using the share widget to capture the URL parameter URL (and short URL).

KevinMacLeodEV · Answer

Share widget link does not seem to remember what basemap was active. Can this be added to the product road map as an ENH?

Also - remember how end users could create their own filter on the fly?  Is that possible in Experience Builder?  Or still something missing?  (Can it be added, if missing?) That's a huge, massive great feature in WebApp Builder.  Hopefully it's something simple I'm missing. Not a complex workaround.

General observation, WebApp Builder was easier to get stuff done as a dev.  Responsive design 'just worked' out of the box, etc. (Yes I know with multiple pages I can have multiple breakpoints etc, but it's tedious. And less customization, no custom breakpoints etc)   And I don't want to wade in to the CSS and TypeScript, I do not have time anymore for that level of work.  WAB customizing under the hood was much simpler and easier. The compilation requirement for TypeScript is a source of greatly increased complexity. In addition to MVC pattern in 4x JSAPI.  I understand TypeScript and MVC make it easier to create Experience Builder itself, as a product.  To develop and deploy custom widgets and customize under the hood, it's now more complex. In addition to the tight version linking between Portal/Enterprise now, with the Exp. Builder Dev Edition, because of 'compiling' widgets, in what is ultimately supposed to be an interpeted language, Javasript.  It is around a year or so, in terms of version matching parity. Many or most customers can only update their ArcGIS Enterprise/Portal stack every few years. So the tight version matching is a particular issue. People will be stuck with old builder versions to compile widgets.  Also note, back when the language was pure and interpeted in WebApp Builder, debugging in F12 on apps in production in user land was much easier and more revealing in terms of what was happening, seeing behavior, and learning what the cause was or was not.  I don't know if it would ever be possible to go back... In JS 5x and whatever is next, after Exp Builder. But I miss JS 3x, before MVC.  And WAB, without the TypeScript. I understand the advantage of both. They offer ultimate flexibility and true power, at the cost of a lot more complexity.   I don't know what the answer is. But, food for thought. I was hopeful for the 'Express Mode' in Experience Builder. But, it doesn't make it act like WebApp Builder, which was what I was hoping for.  Perhaps there can be some way of creating an Express view in the Builder as a dev; and even perhaps, when it comes to code for creating and deploying custom widgets.

MattiasEkstr√∂m · Answer

@inedecubber  I'm not sure if I'm missing something here but isn't what you are doing here exactly what ExB is doing for you if you follow @Shen_Zhang s description in an earlier post here?

inedecubber · Answer

I finally managed to do this, but it's absolutely not "user friendly".

https://experience.arcgis.com/experience/9040777cfe7046fe90a17dfd712b9e49#widget_9=layer_visibility:%7B%22widget_9-dataSource_1%22%3A%7B%22widget_9-dataSource_1-1988a1a4855-layer-2%22%3Atrue%7D%7D

this url activates (makes visible) my layer AED.

I started with a web map, where all my layers are invisible. (if you work with group layers, i only managed to activate the complete group, not one specific layer in a group)

the difficulty is to find the correct id's:

for the layer AED, I found the id by clicking on the data button on the left.

there you can copy the dataid of the web map (dataSource_1, which is my POItotaal).

you can also copy the ID of each published layer, for my AED layer, it is dataSource_1-1988a1a4855-layer-2

you also need to parse the spaces and comma's in the url (as mentioned in the manual of url parameters).

and you also need the number of the map widget (which is 9)

the url I wanted to use, would look like:

https://experience.arcgis.com/experience/9040777cfe7046fe90a17dfd712b9e49#mapall=layer_visibility:POItotaal.AED:true (based on the name of the map widget, the web map and the web map layer).

with such a url, my collegues could easily switch the view of the experience builder, by changing AED by another layer name.

if someone can give a "cleaner" way to activate specific layers, in the url, I would be really happy to read the suggestions!

Ine De Cubber