Action: UPDATE EXISTING ROW(s) using values from this row

This feature request is for a new Action-type that would replace the need for several actions to accomplish the same task:
Update a set of rows using values from this row

Currently we can:
Add a NEW row to another table using values from this row, and
Execute an action on a set of rows

But to pass values from the current row to a set of existing rows requires a bit more setup. This could easily be defined in a single action and could use the same UI as the existing actions:

2X_0_07d9a0f2e09c460101cfe18fc81e2781dd59360c.png

This would really simplify a lot of common routines where you want to push a value from a parent record to multiple child records. And I think it would replace the need for workflows in some cases, making the app more powerful when in offline mode.

Status Under Review
137 43 8,972
43 Comments
aucforum
Bronze 3
Bronze 3

Do they have a new feature request procedure?

What is the current one? Was it an app with voting?

Jonathan_S
New Member

The currant one is at the top of this post. Yes there is a section for feature requests, but please make sure the feature you are looking for has not already been requested :). We want as much concentration of votes on one post so It stands out more

aucforum
Bronze 3
Bronze 3

I was referring the procedure for new feature requests. At one point there was an app with voting, and now there is this forum. However, there is a problem in formally requesting and tracking these New Feature Requests.

Capital_Water_S
New Member

I echo other requestors here. This feature is urgently rquired. It’s surprising that it’s taking so long for Appsheet to act on this request.

Grant_Stead
Silver 5
Silver 5
jtelson
New Member

What is the workaround for actions to target a specific row and update specific column values of that row?

I have an “execute action on a set of rows” that is filtered for the row record that needs updating. Then I have “set the values of some columns on this row”. If I pass through a constant value, it comes through and updates the correct row. If I pass through a [Column Name] value, it’s blank.

What am I missing??

Marc_Dillon
Platinum 1
Platinum 1

I typically add a new “flag” column, set as a DateTime type. On the running of the action, use a grouped action that first sets this column to UTCNOW(). Then you can easily refer to that record later on with

MAXROW( table , “flag” )

jtelson
New Member

Thank you. The critical part is to definitely use UTCNOW() and not NOW() as I found out when working in 2 timezones.

Thanks for the temporary solve, looking forward to the feature request going through.

aucforum
Bronze 3
Bronze 3

Its a good habit. I think all Appsheet Demo Apps, Videos and Webinars should use UTC Date and Time, as part of a Best Practice of development.

hcquadros
New Member

It solves SOME of the problems, but the time is based on the user’s device (and should be, otherwise it wouldn’t work offline).

That workaround is still unreliable for multiple simultaneous users, since a few minutes (even seconds) difference on user’s device time can have some messy results.

Using API I feel is a bit more reliable, but quite complex.

That’s a must have feature and with so many votes and time (it was posted on January), I expected to have at least a “we’re working on it” by now.

Diogo_Ribeiro
New Member

This feature is so much needed. It would solve a lot of problems regarding stocks control.

Is there any preview or intel on whether appsheet will implement it?

Tom_Stevens
Silver 2
Silver 2

Oh man I need this!

Austin
Gold 1
Gold 1

Bump.

pravse
Staff

Yes.

This is a top priority for us to enhance. Let me add some color to this.

We already have actions that can be define to set the value of a column in a particular table (eg: set column X of table T1 to the result of some expression).

When you want to define an action on table T2 that will use values of a T2 row to update some corresponding row of table T1, there are two ways you could imagine defining this:
a) the way @GreenFlux described at the start of this thread — you define an action that specifies T1 and T2 and the binding of values from T1 to T2.
b) allow the notion of a “variable” in the action on T1, and then bind that variable in T2 — this allows the action on T1 to be defined once, but it can be invoked from T2 ot T3 or in general anywhere else as long as the “variable” is bound to a valid expression.
The second model is very similar to the way arguments are passed to procedures or functions in a programming language. We think it is probably the better model to take. However, it is more complicated to implement. That is why it has taken us a while. It requires some surgery to the way actions are implemented today. Along the way, we found that the exact same requirement exists for Workflow Tasks as well — reuse them with different bindings. In 2020, we decided to invest in a richer re-implementation of workflow rules (we’re calling this Process Automation). It is just getting to a preview now. It has needed a significant revamp of the tasks inside workflow rules. Now that we know the shape of that, we’re ready to tackle variable binding for actions and tasks.
So this is at the top of the list for the engineers working on this part of the product. We hope to have this capability in H1 2021.

Koichi_Tsuji
Gold 4
Gold 4

Hi Praveen,
This is interesting.
The user specific “varible” which can be used for any purpose to control the data manipulation within app is currently possible only with the custom user tables to store the values such as row id, list of the values, which will be subsequently consumed for update row, add rows etc. I used this trick here and there, but it is little tricky as we need to fully “sync” the app to update the variable. I remember, it was @MultiTech_Visions Matt who raise the feature request to store the variable within the app.

Update exiting row type of operation could been accomodate by such as user specific variable which could be stored within cilents device without syncing the app fully with the backend server.

In my opinion, as usual.