Discard Edits Help Text showing when no edits have been made (Since Feb 2025 Update)

[KeinanMarks]

I have an experience, hosted and built on AGOL with multiple edit widgets with calculated field values inherited from Smart Forms in the web map. These values include values such as calculated dates. Layers are pulled in from a feature service hosted on Enterprise 11.1

These edit widgets display a selected record, triggered by the user choosing a record either on the map or on a table widget, and edits are typically only made a small percentage of the time. The edit widgets live in a sidebar with different sections depending on what the user is validating.

Since the February 2025 update, each time a user selects a new record, the "Discard Edits" help box pops up for every edit widget with calculated values. This means that the user has to click through "Discard Edits" 3 times every time they go to validate a new record, despite having not actually made any changes themselves. 

This also occurs for edits widgets not currently visible (for example, in a section not currently displayed).

Can this be disabled, or am I missing something? This behavior really shouldn't occur unless the user themselves have made edits (I already require them to manually push the update button to push the edits, which from a UX perspective already suggests that I would rather discard edits than keep potentially incorrect ones).

[ChristopherCounsell]

This behavior changed and not desired.

Selection in an Experience can underpin a lot of actions including filtering and pop-ups.

We want users to be able to select features as part of their interactions with the experience without being forced to open an editing context and discard changes. Make it so that the discard pop-up is contingent on manual interactions with the form in the widget. As others have identified, this was the behavior prior to the update.

Web AppBuilder was a lot more reliable and stable when it came to editing features. We're having an incredibly difficult time making basic editing applications in ArcGIS Experience builder. It's not intuitive and every second release seems to render our applications unusable.

[KeinanMarks]

Hi All,

Our org opened a support ticket and Esri has since confirmed to me that this is a release defect. Hopefully it is resolved soon

[KeinanMarks]

In dealing with this issue I've run into what seems to be another bug that is seriously harming our products and also seems related to the question of what is considered an update in the context of the edit widget. This may have existed before the update, but I honestly would've always assumed user error.

The issue is as follows:

Lets say you have two (or more) edit widgets using forms that hit the same data set, and they are both loaded on the same record from the same selection event in experience builder. These widgets edit different fields with no overlap. If you use the 1st edit widget to make a change, and then use the 2nd edit widget to make a different change, the 1st edit will be reverted, despite the fact that the 2nd edit widget is not set up to write to the field that the 1st edit widget updated. It appears that the edit widgets pushes a full record change based on the record state at the triggering selection event instead of pushing updates to the specific fields touched. Since the 2nd widget isnt updated following the first edit event, it pushes another full record change that reverts even undisplayed fields back to the state they were in at initial selection.

This is pretty baffling to me. I can think of exactly 0 scenarios any user would want an edit widget to potentially make edits to a field that is explicitly not targeted for editing.

[ChristopherCounsell]

I'd consider this expected behaviour. Load a feature for editing, change value(s), submit edit. It's not handling an edit request for each field value. It's returning the feature with some values updated. You can see what the edit request looks like here:

https://developers.arcgis.com/rest/services-reference/enterprise/apply-edits-feature-service-layer/#...

You could avoid fields getting edited by removing them from the form (or disabling editing / removing from the view, if the form isn't enough). This should remove the fields from the update request attributes and prevent the behaviour you are seeing.

I think having two edit widgets in one experience targeting the same layer will give you grief. I've seen weird interactions with active selections, filters and edits. Can't imagine having two edit widgets in the mix. Better to be conservative in level of intricacy we introduce to experiences IMO. I miss Web AppBuilder. As limited as it was relative to experience builder, it was much more reliable and gave us less leeway to take it over the edge / start failing during a regular update.

[KeinanMarks]

Hi Christopher,

---

You could avoid fields getting edited by removing them from the form (or disabling editing / removing from the view, if the form isn't enough). This should remove the fields from the update request attributes and prevent the behaviour you are seeing.

---

This isn't exactly true. the update request as implemented (as you mentioned) sends updates for all fields in a record including the ones explicitly removed from the form.

I understand that the update request does not include updates for individual fields (though the rationale for not allowing partial features in updates is debatable), edit: The request actually works as I would expect but I still think that when pushing an update, non-edited fields should at least retrieve the value of the field at update as opposed to load event. Should not be necessary Otherwise you're opening yourself up to a whole host of potential issues, especially when related to multi-user editing applications. Yes, broadly the answer to that is versioning, but it often shouldn't be.

In my case, I provide the user with two widgets representing two different edit paths. Each fill flags in other fields for background processes to deal with. Without propagation in calculated field values (which would fix basically all of my problems) this is about as elegant of a solution as is available to me (without throwing it away and building custom).

Edit: As far as I can tell the edit widget is simply sending updates for all fields when it it not necessary to do so.

[ChristopherCounsell]

Make the field non editable or remove it from the view, if possible, and
see if that works.

[KeinanMarks]

No, the implementation on the edit widget appears to be incorrect.

I just confirmed by sending the request manually that sending an update request with only the fields that you intend to edit works as expected. I also confirmed that the edit widget with only a selection of fields added sends an update request with ALL fields present in the record.

I stand by my initial post. It appears that the edit widget is sending edits to fields it should not be touching.

[ChristopherCounsell]

Manually via REST? Where we can specify the fields?

You should be able to demonstrate the fields included (or omitted) in the
edit widget update request by monitoring the network traffic.

If the widget includes all editable fields in the layer you have two
options:

Disable the edit capability on the view of fields you do not want to be
updated, or remove the field from the view altogether.

Take this to ESRI as a potential bug or enhancement request. If it's not
expected behaviour it's a bug. If it is, you'll have to explain why the
behaviour should change e.g existing options aren't enough, business
benefits.

Hope that helps. I still think you'll get raised eyebrows at having two
edit widgets on the same layer. I've never seen this before.

[KeinanMarks]

---

@ChristopherCounsell wrote:
Manually via REST? Where we can specify the fields?

Yes, in the attributes key of a feature (feature[attributes]) include only the attribute:value pairs you intend to update. eg in the feature below in the updates list:

{
   "attributes": {
    "last_edited_user": "keinan.marks",
    "created_user": "",
    "last_edit_time": 1745533036371,
    "globalid": "{gid}"
    "created_date": 1743524328123,
    "objectid": 2,
    "comment": "This is a comment"
    "status": "Incomplete"
   }

 send only 

{
   "attributes": {
    "globalid": "{gid}",
    "objectid": 2,
    "status": "Complete"
   }

 and the record should update the status field. The payload includes only those fields and the record will update as expected.

The issue isn't only for applications for multiple edit widgets. If a user selects a record, walks away, or say, does external research on a potential change, and the record is updated by another user in any context, those updates will be overwritten when the first user actually makes the change. This would be expected for fields actually editable by the user, but currently includes ALL fields on the record.

Edit: should mention works via both applyEdits and updateFeatures