Embedding dashboards in ArcGIS Experience Builder and Hub sites

One storm, two audiences. Picture the night a storm rolls through your service area. Power is out in three districts, a water main has broken on Harbor Road, and the phones won't stop ringing. Residents want to know when the lights come back, so the communications team asks for the outage dashboard on the city's public Hub site. At the same time, the emergency operations center wants that same dashboard inside its internal Experience Builder app, next to crew rosters and shelter lists. Do you build two dashboards? No. You build one and embed it in both places. That's what this lesson is about: putting a dashboard where people already work, without doubling your maintenance.

What you will learn. By the end of this lesson you'll be able to do three things. First, embed a dashboard inside an ArcGIS Experience Builder app, so it sits alongside other widgets on one page. Second, add a dashboard to a page on an ArcGIS Hub site, which is the usual public face for a city or utility. Third, use URL parameters and sharing settings together, so every audience sees the right slice of the data and nobody hits a surprise sign-in screen. We'll work through a storm response example the whole way.

What embedding really means. Let's be clear about what embedding is, because it explains every behavior you'll see later. When you embed a dashboard, the host page doesn't copy it. It opens a window onto the live dashboard. That window is called an iframe, which is simply a web page displayed inside another web page. Think of a window in a wall: you're looking at the same street outside, not a painting of it. The dashboard keeps its own URL and its own item in ArcGIS Online. So when you fix a gauge or add an indicator, every place that embeds it shows the change right away.

Experience Builder: the Embed widget. In Experience Builder, the tool is the Embed widget. Open your app, drag an Embed widget onto the page, and choose the option to embed by URL. Paste the dashboard's URL, which you copy from the dashboard's item page or from the browser while viewing it. Then size the widget in the layout. For the operations center, you might put the storm dashboard on the left two thirds of the screen and a text widget with shift contacts on the right. Save and publish the app. One thing to know: the embedded dashboard runs on its own, so its selections don't filter other Experience Builder widgets.

Hub sites: the Embed card. On an ArcGIS Hub site, the equivalent is the Embed card in the site editor. Open the page where residents look for storm information, add a row, drop in an Embed card, and paste the same dashboard URL. Give the card a height that fits the dashboard, because a card that's too short gives visitors two scroll bars, one for the page and one inside the dashboard, and that feels broken on a phone. Add a short text card above it that says what the map shows and when it refreshes. That little bit of context cuts a surprising number of calls to the service desk.

Worked example: one dashboard, many views. Here's the shortcut that saves you from building a dashboard per district. In the dashboard's settings, open URL parameters. Add a category parameter named district, choose the outage layer as its data source and the District field as the field to filter. Then pick the elements it filters, such as the map, the list and the indicators, and save. Now any embed can pass a value at the end of the URL, after a hash sign. Here are the three finished links, one for each district page on the Hub site. Where it says ITEM_ID, your own dashboard's item ID goes, a 32-character code you copy from its item page. Notice that Harbor View contains a space, so it's written as percent twenty, which is simply the web's way of writing a space safely. Each district page embeds the same dashboard, already filtered to its own outages.

Follow one request. Let's trace what actually happens. A resident opens the storm page on the Hub site. The page loads the dashboard in its iframe, and everything after that happens inside ArcGIS Online. Now follow a single request slowly. The dashboard asks the public layer view for current outages. The view reads from the outage layer behind it, returns only the fields and rows it's allowed to expose, and the dashboard draws them. At every hop, ArcGIS checks who's asking and what the item is shared with. The Hub page itself grants nothing. It's just the frame.

Sizing and the phone in the pocket. Most visitors to a storm page arrive on a phone, often with low battery and a weak signal. Inside an embed, the dashboard's layout follows the width and height of the iframe, not the size of the device. An embed has a fixed height, but the dashboard reflows to fit the space it's given, so a dashboard that looked great on your monitor can collapse into a cramped strip. The good news is that the mobile layout you designed in the last lesson still applies inside the embed. Open the published page on a real phone, not just a narrow browser window. And add a plain link under the embed that opens the dashboard full screen, for anyone who needs more room.

Match the embed to the audience. Every embed has an audience, and the sharing chain has to match it end to end: the site or app, the dashboard, the web map its map element uses, and every layer or layer view it reads. For the public storm page, the Hub site, the dashboard, the web map and the layer view must all be public. For the operations center app, share the app, the dashboard, the web map and the layers with the emergency operations group instead. Everything the dashboard reads must be shared with the audience, but the source layer behind a public view can stay private, because the public only ever reads the view. Use views to leave out sensitive fields, like customer names on service requests or the addresses of critical care customers. That way the public and internal embeds can come from the same source data without exposing anything you shouldn't.

Common mistake: the surprise sign-in. Here's the mistake that catches almost everyone. You share the Hub site publicly but leave the dashboard, its web map, or one of its layers shared only with your organization. You check the page and it looks perfect, because you're signed in. Meanwhile residents get a sign-in prompt where the outage map should be, and the communications team starts getting angry emails. Sometimes it's subtler: the dashboard is public but a web map or layer isn't, so visitors may see a sign-in prompt or some elements simply stay empty. You can't judge this from your own screen. Testing signed out is the only reliable check, so always open the published page in a private browser window, signed out, before you announce it.

Recap. Let's pull it together. First, embedding puts a live window onto one dashboard, so you maintain it once and every page stays current. Second, in Experience Builder you use the Embed widget, and on a Hub site you use the Embed card, both by pasting the dashboard URL. Third, URL parameters let each page show its own slice, like one district, while sharing decides who can see anything at all. Fourth, test every public embed in a private window, signed out, before anyone else sees it. With those four habits you can serve residents and your operations center from the same dashboard.

Your exercise. Before the next lesson, try this. Take a dashboard you've already built, for example service requests or traffic incidents, and add a URL parameter that filters by district or category. Embed it twice, once for each of two values, on a Hub site page or in an Experience Builder app. Then open the published page in a private browser window, signed out, and write down what you see. If anything asks you to sign in or stays blank, trace the sharing chain and fix it. Next time we'll make sure these embeds load quickly with performance tuning.