nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ExB Widget share not mandatory

LouisViallet

In Experience Builder, all widgets add in the builder must be shared with the user to load the experience. If a widget is not shared, the experience is not loaded and the user will get a blank page with error. We can say that widget's share is mandatory. For ESRI, it's "as designed".

In WebAppBuilder, when a widget was'nt shared, the WebApp was loaded correctly without the unshared widget. It was perfect to manage user's rights.

My idea is to have the save behavior in Experience Builder : be able to load an Experience without a unshared widget.

Thanks

Vind meer berichten getagd met

ArcGIS Enterprise

Widget

Status: Openen

Reacties

TimWestern

Yeah, I get why that feels like a regression. Web AppBuilder was more forgiving here, while Experience Builder seems to treat widgets as required parts of the experience rather than optional pieces it can just skip.

My guess is that this is more about Experience Builder’s architecture than React by itself. In other words, it’s probably not that this is impossible in theory, but that EXB was designed around resolving all referenced items up front, which makes an unshared widget a blocking problem.

I do think that means sharing is no longer a good way to control widget-level access in EXB, even though it worked that way in WAB. So the use case makes sense — it’s just not a pattern EXB currently seems designed to support.

However, ESRI can always consider that in future roll outs potentially, whenever it could be addressed.

LouisViallet

I understand the current behavior, it's just that in experience it's now a blocking load system and in WebAppBuilder it was a functionality to load without blocking app.
For me, it's a functionality regression.

LouisViallet

I understand the current behavior, it’s just that in experience it’s now a blocking load system and in WebAppBuilder it was a functionality to load without blocking app.

For me, it’s a functionality regression.

We want to manage the accessibility/right on a widget with share option and now it's not possible with ExperienceBuilder. I think it's possible to manage that with React with a test depending of share option.

TimWestern

Programmers Hat on for a second:

I get this seems like an 'Idea', it feels like a place where EXB doesn't fully match or replace functionality in WAB.

However the way React handles dependencies, (which is the tool that Experience Builder is built on top of), if a dependency or import cannot be loaded or found it can and will cause issues, often preventing the app or a part of it from loading at all. This is by design I think, and I am not aware of anyway that could be changed with how React works currently. (If I'm wrong I'd love to hear how though).

What I hope my previous post can help with, is consider how and why you might have one-off or group deviations in how they use the app, and be able to instead leverage that knowledge to provide those experiences without having the fail through problem. If there is more to this than what I understand, I'd be glad to hear it though.

TimWestern

TLDR:

What you’re describing usually happens when there’s a mismatch between how the Experience and its dependent items are shared.
In Experience Builder, the app doesn’t just contain widgets—it references multiple items (widgets, maps, layers), and the user must have access to all of them.
For example:
If the Experience is shared to a group
But a widget used in that Experience is not shared to that same group
Then the app may fail to load or appear blank, because it cannot resolve that dependency.
This is different from Web AppBuilder, which could simply skip rendering an inaccessible widget.
Some key things to watch for:
Make sure all widgets are shared to the same audience as the Experience
Ensure maps and feature layers used by widgets are also shared appropriately
Avoid using sharing as a way to hide widgets—use visibility rules instead
In short: all referenced items must be accessible, or the Experience may not load correctly.

When you say a widget must be shared I'm trying to see if I understand your scenario.

Scenario A (Most Common)

Experience is shared to a group
Widget is NOT shared to that same group

What happens:

User can open the Experience ✔️
Experience tries to load widget ❌
User does NOT have access to widget
App may fail / blank page / errors

✔️ This is the classic EXB “gotcha”

Scenario B (Also valid, but just a variation)

Widget owned by admin, not shared
Experience shared to others

What happens:

Same result as A
Ownership doesn’t matter—sharing does

If it’s not shared → it doesn’t exist to the user

The way I try to keep this straight is to think like this:

Instead of thinking:

“Experience contains widgets”

Think:

“Experience references multiple Portal items”

Each of these must be accessible:

Experience item
Widget items (especially custom widgets)
Web maps
Feature layers
Data sources

If any one of them is inaccessible, things break.

Now the entire experience may not break, but parts of it may.

Also, btw if some layers are federated or loaded from other URLs CORS errors (Cross-Origin Resource Sharing) can be something that has to be resolved between you and wherever that feature /map was hosted also, and those settings are server wide not experience or shared item setup typically.

Things to watch out for:

Gotcha #1 — Widgets are Items (not just code)

Custom widgets are Portal/AGOL items
They must be shared like:

Web maps
Feature layers

People forget this ALL the time

Gotcha #2 — Group mismatch

Experience shared to Group A
Widget shared to Group B

User in Group A only = :collision: failure

Gotcha #3 — Indirect dependencies

Even if widget is shared:

Widget → references a map
Map → references a layer
Layer → not shared

Widget fails (sometimes silently)

Gotcha #4 — Dev vs Prod environments

Widget shared in DEV
Experience moved to PROD
Widget not shared in PROD

Works for you, breaks for users

1. Ensure widget is available to everyone who can access the experience

So the Safest approach:

Share EVERYTHING consistently:

Experience
Widgets
Maps
Layers

Same audience, same sharing level:

Rule of thumb:

“If a user can open the app, they should have access to every dependency.”

If there are exceptions, then you need to know clearly how that would work.

Note, because of how experiences work, I think you can clone and make slight variations of them if different groups have different needs to some degree. One example might be, public vs internal users.

2. Can you make a widget unavailable to certain users?

:prohibited: Not via sharing (in EXB)

Because:

If it’s not shared → app may break

✔️ Instead use:

Visibility rules
Separate experiences

This is a big conceptual shift from Web AppBuilder

3 What about feature layers and data permissions?

This is where things get subtle.

Case A: Layer NOT shared

Widget loads
Data fails

User sees:

Empty results
Errors
Partial UI

Case B: Layer secured (token/auth)

Widget loads
Prompts login or fails depending on config

Case C: Layer shared properly

✔️ Everything works as expected

Key takeaway for data:

Data permissions affect behavior
Widget permissions affect app loading

I hope this is helpful

Doe mee aan het gesprek

Meld je aan om te posten, content te volgen en meer. Nieuw hier? Registreer gratis.