Restart auto-edit action when table is refreshed

This is confirmed internally, with a small nuance.

Refresh table itself does not end or restart an active edit action. With auto-edit enabled, the edit session remains open. When the record is updated in the background, the next user change triggers the “modified by another party” message- not only because auto-edit is active, but also because the record changed underneath the edit session.

There is currently no explicit (auto)save or cancel process flow action that can be triggered on refresh.

One possible workaround is to force an autosave by navigation, e.g.:

• Go to next row

• then Go to row for the original key

This ends the edit implicitly and avoids the conflict.

Restarting the edit action on refresh (or having a save/cancel process flow action) would require new platform functionality, so this sounds like a good candidate for an idea post.

Thanks Poonam, in my case it’s a form edit, without the grid visible (the screen always contains a single record), so switching rows is not an option. I can see how this is also the reason the auto-edit stays active the whole time, as we are technically editing the same row without exiting it.

Could you change the thread type to an idea for me?

To summarize: the idea is to restart the edit action on table refresh, or to add a new option in process flows that restarts auto-edit on a specific table.

​@jkruter 

You are free to raise a ticket since Arie thinks this is a bug. But I think this could be solved with the auto-commit logic concept https://docs.thinkwisesoftware.com/docs/sf/business_logic#auto-commit/. You might need to move some things around, but what you are describing is why we made this.

Thank you for bringing this to my attention, it works exactly like I would like the auto-save function to work (saving directly after exiting an input field, not only before starting the next action). I'll for sure be using this in the future, and I think this will solve another more minor issue I have,

Sadly it does not seem to be restarting the edit session, when the table gets refreshed, any edits after that fail because the table was "modified by another party after the edit action was started” (again, even though it was refreshed after the mentioned modification).

Ok, then this might still be a bug. But I couldn’t let this go, because I saw that what you were trying to do was the use case for this functionality. It does come with a performance penalty, so don’t use this for everything!