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; } } }

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

discard.PNG

KeyboardShortcuts1.JPG

Finde mehr Beiträge mit dem Tag

Accepted answers

KeinanMarks

This issue appears to be solved as of the June 2025 update

All comments

SidneyMechling

I am having this same issue! This has slowed down my typical workflow and I would love to have the ability to turn this pop up off or have the old version back.

ScottJackson_lasan

This issue is definitely slowing down workflow. In my organization, we are focusing on building apps for our non-GIS staff to use and I'm afraid that an issue like this could discourage staff from wanting to use and adopt the workflow we are providing through the apps. Please get this resolved asap.

Allen_Zhang

Hi all.

I made a demo of Maps SDK's Editor widget(which is the underlying component of the ExB's Edit widget map mode), and this issue happens when the computed date field's arcade expression returns empty or null. Select any feature and then click the back button, the discard warning will pop up:

https://codepen.io/kaifeiji/pen/gbOLVbV

After digging, I found that the date field was set to NaN instead of null. Maybe it's the reason?

KeinanMarks

Hi Allen,

I believe this is a different Discard Edits help text. I am not referring to the one in the edit widget itself (although that behavior also seems to have changed). In Experience Builder there is now a help text with screen wide transparency that draws over the entire Experience (an additional time for each widget). This is in addition to the Discard Edits box on the edit widget. The user must clear these screen wide pop-ups.

That being said, none of my calculated values have NaN (or even null) outputs, all but one of them simply push the AGOL username and current date back to enterprise.

Allen_Zhang

Thank you Keinan.

The key is that the widget wrongly considers that some fields are changed even when the user inputs nothing.

The NaN/null may be one case, and yours is another.

I'll test the Now() and GetUser().

Would it be convenient to provide the calculated fields' arcade expressions? That would be more helpful.

KeinanMarks

Sure,

The current date function is just:

Now()

The user function is:

var p = Portal('https://www.arcgis.com');

var u = getUser(p);

if (u == null){ var user = 'No User'

}

var user = Text(u.username)

return user

The message occurs even when all the calculated values are set to return a set value (eg, return a defined string for user name, arcade Date type for date. I have rebuilt the edit widgets completely fresh, new map, new experience (with only map, edit widget and table widget for selection) as well as defined calculated outputs (again, for only two calculated values), and am still having the issue.

The only other difference (assuming this isn't a widespread reproducible issue) I can think of is that the Enterprise server is internal.

KeinanMarks

Edit: Removed

TianWen

Thanks for your post! The warning dialog popup is intended behavior, as the calculated expression modifies the field value each time a feature is selected, and the edits remain unsaved. In this case, we recommend avoiding the use of Arcade to update field values. Instead, if you’d like to display certain information, such as a username or date, you can use Smart Forms and place the expression in an info form element.

SidneyMechling

Prior to the new update the warning was only showing in the editor widget and you could still click around in a table without issues. Now when I am just clicking points in a table to show them on the map, the entire screen grays out and I cannot complete any functions until I press "Discard Edits". For my projects, arcade is mandatory for my forms. There are no work arounds for the type of data being collected. Can we please revert this change back to how it functioned before? It would still give you an error in the editor widget but it wouldn't disrupt your entire experience and shut down every function until you hit a button once if not twice to get it to go away.

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

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

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/#request-parameters

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

This issue appears to be solved as of the June 2025 update

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.