Experience Builder Editor not honoring settings when accessed as related record

[SFM_TravisBott]

Having some more odd behavior with the Experience Builder Editor widget where it's not honoring defined settings when accessing a related record.

I have multiple layers and I want different editing capabilities for each. The app has been published with an attribute-only edit functionality for the Treatments layer.

In the Editor, with nothing selected, the option to add a record to the treatment layer is disabled, as desired....You can see below where it's not an option in the Editor.

However, when I select the parent record, and I navigate down to the related Treatment records (which I would like to be able to do), you can still see '+ Add Feature' is available, and you can still add features, which is what I explicitly disabled. The ability to edit in this fashion is enabled in the Form in the webmap, but there's no option to specify editing type.

Could someone in in the community help out with a workaround, or, better yet, can somebody with Esri patch this up?

[VenkataKondepati]

Hi @SFM_TravisBott,

What you’re seeing is the Editor widget not fully honoring the editing settings defined at the layer level, especially when it comes to related records. Even though you’ve disabled geometry editing or creation for the Treatments layer at the map level, once you access it through a parent feature, the widget still exposes the + Add Feature option — basically ignoring your intended restriction.

From what I’ve seen, the widget relies more on what’s defined in the form configuration of the web map than on what you set in Experience Builder’s widget config. And unfortunately, when editing related tables or layers, it doesn’t give you granular control over what’s allowed — like attribute-only edits vs. feature creation.

A couple of things to try:
Remove the form from the web map for the related Treatments layer — that sometimes disables the inline add behavior in the Editor.

Or, split the editing across separate apps if possible — use one app for viewing related records, and another (with stricter controls) for edits.

I’d also suggest logging this with Esri or posting it to the Ideas site — this really should be handled better out of the box.

You’re not missing anything — this looks like a gap in how Experience Builder interprets editing permissions once you go one level deep.

I hope this helps and let me know.

Regards,

Venkat

[AlixVezina]

@VenkataKondepati Thanks for posting this, there are in fact some limitations when using Attribute Only mode and I think you're correctly pointing to one of them. I'm checking with the team for more info on this case and any plans moving forward.

[VenkataKondepati]

Hi @AlixVezina,

Thanks for checking quickly and prompt response.

Regards,

Venkat

[SFM_TravisBott]

@VenkataKondepati Thanks for the detailed response.

I can certainly look at other ways to get a little more creative with editing. Our users have a decent out, in that all of the data collected is generated through Survey123 and the pop-up contains a URL parameter so they can edit their data in Survey. However, there are lots of small edits that might take place within the workflow, and the functionality of the List Widget + Editor is nice, and much preferred, so long as it works.

Building the app on a View, which doesn't allow geometry editing at all (and would therefore disallow adding a new feature), might work, but I've been moving away from Views as any updates get complicated.

[AlixVezina · Accepted solution]

@VenkataKondepati @SFM_TravisBott ,

I have confirmed with the team again that related records can be created or updated if the update capability of the parent layer is toggled on. So the child layer's privileges cannot be dissociated from the parent. Experience Builder is dependent on how this was implemented across the platform.

@SFM_TravisBott, I think something else that may be interesting to explore is if you are able to leverage the conditional editability and/or visibility logic for related records when configuring the Form for your parent layer. You can turn off editability for related records there. I think you could also add a condition so related records can only be edited based on if the parent feature is being added or updated, so even write up some attribute lofic to determine editability/visibility.

As @VenkataKondepati  suggested, you're welcome to log a new idea with your request and detailed use case. I think I would add it to the more general ArcGIS Online ideas area: ArcGIS Online Ideas - Esri Community

[VenkataKondepati]

Thanks @AlixVezina.

[SFM_TravisBott]

@AlixVezina Thank you following up. This is when this forum is at its best. As users we're often confronted with situations where we're just not sure what's possible, as the products move fast and the documentation doesn't keep up. So it's nice when someone from Esri can pop in and provide a "yeah, don't even bother it's not possible" kind of answer before we waste more time pursuing it.

On another note, it would be wonderful if this was different! Seems a shame when settings that you can specify do not actually get honored.

[AlixVezina]

@SFM_TravisBott I totally understand. If you have any other questions and feedback, or need any further assistance, always feel free to reach out: avezina@esri.com.

[AlixVezina]

@SFM_TravisBott If you're an org admin or own the editable layer, you'll still be able to edit the data after you've turned the options off. You'll need to publish your app and access it with a different editing user to see the restrictions you've implemented in the app.

See: Solved: 'Edit' widget ignores capabilities - Esri Community