Reset on edit functionality explanation (draft in progress)

There are myriad discussions in the community of the column-level Reset on edit property, but no comprehensive summary of its nuanced behavior, which is crucial to understand when using this column feature. Also, there's barely any explanation in AppSheet Help.

So, here's an attempt to crowdsource reliable information in a centralized post for everyone's reference. I'm starting by drafting my own understanding, and can update the post to incorporate other's contributions in any replies. To be clear, my understanding is definitely incomplete and potentially imprecise or outright inaccurate. Corrections and other contributions are welcome.

Summary

A column's Reset on edit property is evaluated when an existing row enters edit mode. If the property is enabled (or its expression evaluates to true), then standard Initial value functionality applies for the column just as if the row were being initially added. In addition, the row's pre-edit values are available for reference in expressions used in the column's properties, including Reset on edit and Initial value.

Applicability: "when an existing row enters edit mode"

"an existing row"

A column's Reset on edit property is evaluated only for an existing row--it is not applicable in any way to a newly added row.

  • Note: An Initial value expression can include conditional logic. Sometimes, it's helpful to incorporate conditions into a column's Initial value expression rather than its Reset on edit expression so that that logic is applied both when a row is initially created and whenever it is subsequently edited. If a condition exists only in the Reset on edit property, it's not applied upon initial row creation.

"enters edit mode"

A column's Reset on edit property is evaluated when:

  • A row is edited via the following methods that are indicated as applicable.
  • The edit process (using an applicable row edit method) commences for a row, which occurs as described.
Row edit method Does Reset on edit apply? When does edit process commence?
Form view Yes User opens form
Quick edit (detail view) ? ?
Quick edit (table view) ? ?
Data change action (in app) ? ?
Data change action (in automation)

?

2025-05-25: In the course of developing an app feature I'm working on, I *think* I have confirmed that this cell is "No" (i.e., Reset on edit does not apply).

?
Data change action (via AppSheet API) ? ?

Behavior: "standard Initial value functionality"

Just as when a row is initially created, its Initial value expression recalculates as applicable until it is directly edited. If the expression references the row's other columns, its result is recalculated each time those other columns' values change during the edit session--unless and until the column itself has a value directly entered by the user or a system action, in which case this entered value overrides the result of the Initial value expression.

Data: "pre-edit values are available for reference"

Since the row already exists, its before values are available for reference using [_THISROW_BEFORE].

  • Note: Since a column's Reset on edit property is evaluated when the edit process commences, the row's after values are not applicable--i.e., they don't yet exist.

In other words:

Column reference Value
[_THISROW_BEFORE].[Column] The column's value immediately prior to the edit session. 
[Column] The column's value during the edit session.
[_THISROW_AFTER].[Column] N/A

 

5 9 634
9 REPLIES 9

Thank you so much for this post @dbaum 

Here are also some insights about Reset on Edit. For example:

  • Checking if a Reset on Edit did happen while opening the form
  • Checking if the value was changed while in the form

Oddly (I kept saying this is a bug), [_THISROW_AFTER].[Column] will not work on the client side. Only work on the server side. (so you can only emply this [_THISROW_AFTER].[Column] expression when it comes to BOT/Automation.  Huge  bug, but google not admit.

If I could add more, this is inheritating bug (off course Google never admit), then during the dicussion for that, I admitted that this is coming from technical difficulties (like Mr. Big, technical difficulties), then I suggested (to Google ) you better to document that. But such opinion never being taken.

IN() expession being used in slice filter condition never gonna works for some years.  If you pass such type of filder condition, AppShee expression parser accept. But View out of it shows wrong resutl. This could be coming from inheritanig bug on AppSheet, but never being addressed after our loud voices.

Then the dev recources are spent to the new features which will help 1% customer, or satisfy the own challenges . Then our mind for appsheet is destroyed . This happens daily.

 

Roderick
Community Manager
Community Manager

Thanks for the feedback all -- I'll work on opening a bug on our end to get an engineer to take a closer look. Please continue to share any additional insights! 

 

@Roderick I would like to suggest a new section of the Appsheet community, dedicated to bug reports by end users. I know it's a lot to ask for the AppSheet team to monitor every new thread to keep an eye out for bug reports, but maybe by making a separate section it can call attention to those posts and the team can monitor them better. 

Thank you

This is something we are looking into! Currently you can use the "bug" tag and it will be flagged by the team. We are working on a process to post updates on bugs similar to how we share release notes. 

 

 

Any progress on clarifying and augmenting documentation of this feature's behavior, @Roderick or @lizlynch ?

Apologies, @dbaum . It is on my list of doc enhancements. Just haven't had the opportunity to check it off the list just yet. Truly appreciate that you have taken the time to write this article and look to help enhance the documentation. Will try and prioritize this.

Top Labels in this Space