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

[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

[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.

[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. 

[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.

[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.