Why don't we have a way to easily detect ADD or EDIT mode when opening a Form - like this?

[WillowMobileSys]

In email body or template we can use the variable shown below.  There are many use cases on a From view where we need to take different actions based on if the Form is being used to add a new row or if it is being used to Edit an existing row.

It seems extremely odd to me that we have an email variable to be able to report if the mode was ADD or EDIT/UPDATE but we don't have that capability to easily do the same in a Form View.  The only way I know to detect this mode is based on if the row exists in the table or not - i.e. on an ADD it will not yet exist in the table.

It would be so much easier and more reliable if we could ask the app what mode it thinks its in!

Have I been missing something all these years?

[Markus_Malessa]

I agree, and I'm not sure that you're missing something. For me it's as simple as changing the label on the form to 'Add New' vs 'Edit'. On the very rare occasion I even just use two separate forms, but that usually only occurs if there is a difference on the column list that is available on Add vs Edit forms.

[Jonathon]

Agreed, an easier expression here would be nice.. In the meantime, if anyone stumbles on this thread an needs a solution:

I typically add 2 datetime columns, created and updated, with initial values of UTCNOW() and updated resetting on edit. This serves as a basic audit trail, but can also be used to detect row creation from row updates.

IF([created]=[updated],"new row","update row")

I used to use this expression which would work without created/updated columns, but it won't work on the new desktop mode:

IF(IN([_THISROW],Table[KeyColumn]),"Update row","New row")

The above took advantage of the fact that a row doesn't exist in the table until it's saved; the new desktop mode seems to have changed that and the rows now exist in a generic Table[Column] query before they've been saved.

[Steve]

Is this a new row?/Does this row already exist?

[WillowMobileSys]

---

@Jonathon wrote:

the new desktop mode seems to have changed that and the rows now exist in a generic Table[Column] query before they've been saved.

---

Hmmm, really?   That seems like a significant backwards compatibility design flaw.  Wouldn't apps that rely on your second approach, of detecting New from Update, start breaking?  There are probably other implementations that also leverage the fact that rows don't yet exist in the Table on an ADD.

Secondly, I don't see the advantage of adding a row BEFORE it is saved?   And it also must be then that it is added immediately and then kept updated as the user fills out the Form?  Why have the extra overhead?  There are probably use cases that warrant it.  I'm just not seeing it.

[Jonathon]

To clarify, the rows aren't physically added to the database until saved/synced as it's always been.

IN([_THISROW], ThisTable[KeyColumn])

Previously the above expression would return false for new records, and true for existing records. Now, it will always return true.

[SkrOYC]

---

@Jonathon wrote:

the rows aren't physically added to the database until saved/synced as it's always been.

---

It's like it's adding them on the go to the local storage database and when you hit save it just closes the process, while if you hit cancel it removes what it did.

Previously (and with the mobile view) it was the other way around

[SkrOYC]

---

@Jonathon wrote:

I used to use this expression which would work without created/updated columns, but it won't work on the new desktop mode:

IF(IN([_THISROW],Table[KeyColumn]),"Update row","New row")

The above took advantage of the fact that a row doesn't exist in the table until it's saved; the new desktop mode seems to have changed that and the rows now exist in a generic Table[Column] query before they've been saved.

---

Yes, it's a ABSOLUTE pain that IMO NEEDS to be fixed
https://www.googlecloudcommunity.com/gc/Announcements/In-Preview-New-UI-design-for-desktop-users/m-p...

[Steve]

Both the new desktop and database features in preview seem to cast aside existing mechanics in favor of some new vision.

[SkrOYC]

It would be great to understand this new move. If it's something that can put us closer to Real Time Database, awesome! But we have no idea and worst yet we have to treasure hunt this marvelous new quirks 😒

[Jonathon]

Yeah, this should be opt-in similar to the consistent vs legacy blank value comparison modes.

Generally speaking, I prefer the new functionality... but it is a huge pain having to review old applications.

[WillowMobileSys]

---

@Steve wrote:

Both the new desktop and database features in preview seem to cast aside existing mechanics in favor of some new vision.

---

Personally, I think that is fine if they are working towards some new grand capabilities PROVIDED they:

• Recognize impact to existing apps and customers
• Notify all App Creators of imminent changes coming that may break apps and recommendations on how to avoid impact.

This is common industry courtesy whenever there are breaking changes coming soon.  The new Automation may not have migrated as well as hoped when it was first deployed, but at least we were all well aware it was coming!

[Steve]

Yeah, my fear is they don't realize they're deviating from the existing model. As evidenced by the recent Synchronizing... localization fiasco, there are developers who don't know the product, and insufficient oversight.

[SkrOYC]

---

@Jonathon wrote:

Agreed, an easier expression here would be nice.. In the meantime, if anyone stumbles on this thread an needs a solution:

I typically add 2 datetime columns, created and updated, with initial values of UTCNOW() and updated resetting on edit. This serves as a basic audit trail, but can also be used to detect row creation from row updates.

IF([created]=[updated],"new row","update row")

---

Thanks for the idea btw.
I was trying different methods for a new way to identify new row vs update row and since I also have a [created_at] (Initial with NOW()) and [modified_at] (ChangeTimeStamp) I ended pointing the Initial for the [created_at] to the value of [modified_at], which the first time will make both fields equal. Btw, NOW() takes the datetime of Form opening, while ChangeTimeStamp updates to the last modification, like Form save datetime, and it's fine for my usecase.

Thanks again

[Jonathon]

---

@SkrOYC wrote:

Btw, NOW() takes the datetime of Form opening, while ChangeTimeStamp updates to the last modification, like Form save datetime, and it's fine for my usecase.

---

Unfortunately ChangeTimeStamp doesn't give UTC timestamps, so if those are a requirement then Datetime with initial value of UTCNOW() and reset on edit checked is the way to go!

[SkrOYC]

Yep, I was thinking about that when I saw you using UTCNOW().

I guess you know about this but USERTZOFFSET() might also be useful

USERTZOFFSET() - AppSheet Help