On form submit, need data in source row updated, NOT new row added

[SparklyGeek]

Hello again; this is my third question regarding the same project, the moving form. Now making my first foray into Actions, and again am finding it all less intuitive than I had hoped for.

As I mentioned in my earlier posts, this project entails a Form view in which the form user may select a Customer Name - Date combination from a drop-down menu, and have information loaded from the source sheet into appropriate fields. So, referring to the screen snap below, if the User selects "23/04/15 Sat — Julie McDougal", data from Row 5 appears in the corresponding fields in the form (see cell E5).

This is all working fine, but I'm having trouble with the form submission actions.

There are a few things that are supposed to happen when the form is submitted; I'll keep the scope of this post limited to the simple parts. The data the user submits needs to be written to the appropriate fields of the SAME row the initial values were drawn from, not added as a new row at the bottom, as you can see has happened twice in this particular screen snap.

This needs to happen without overwriting data in columns that are not represented on the form.

I thought "App:Edit this row" would be the answer, but this did not affect the way the app behaved at all. 

Then I thought I would put that aside and try the next thing the form submission is supposed to do: change the value of the "Status" field to "completed." I tried changing  "App:Edit this row" to "App:Set the values of some columns in this row"; see screen snap below. This had absolutely no effect, either; the new data continued to come in to a new last row AND the Status column remained blank.

So how does one actually do this?
Thank you for your help!

[dbaum]

Without having dived into all the details you specify here nor the prior posts you mention, here's some general guidance regarding ways to enable editing part of an existing row.

---

@SparklyGeek wrote:

"App:Set the values of some columns in this row"

---

If you only need minimal information from the user, this technique can work in combination with the INPUT function.

---

@SparklyGeek wrote:

"App:Edit this row"

---

Consider creating a separate form view that includes only the columns you want to capture--potentially based on a slice that's limited to those columns.

[SparklyGeek]

Without having dived into all the details you specify here nor the prior posts you mention, here's some general guidance regarding ways to enable editing part of an existing row.

Where? Did you mean to link to an article?

If you only need minimal information from the user, this technique can work in combination with the INPUT function.

Not following you, but again I think you're referring to an article you meant to link to? Anyway, no, I wouldn't describe 19 fields as minimal. 

Consider creating a separate form view that includes only the columns you want to capture--potentially based on a slice that's limited to those columns.

Sorry, how would that help with this issue?

[dbaum]

---

@SparklyGeek wrote:

Where? Did you mean to link to an article?

---

No. I was referencing the techniques I described in my reply--not any separate article.

---

@SparklyGeek wrote:

Not following you, but again I think you're referring to an article you meant to link to?

---

Yes, the INPUT function that I linked to.

---

@SparklyGeek wrote:

Anyway, no, I wouldn't describe 19 fields as minimal.

---

Agree. If you need that many inputs from the user, the INPUT function is likely not a good technique.

---

@SparklyGeek wrote:

Sorry, how would that help with this issue?

---

In skimming your post, it sounds like you want a user to be able to edit a subset of a row's columns. Excluding the other columns from the form is one way to preclude the user even having access to the other columns.

[SparklyGeek]

If I may bump my own question, I'm surprised no one has solved this. Doesn't seem like an extraordinary problem; is it?

[dbaum]

I read through your original post here more closely. I wonder whether the fundamental issue is which action is being used to open the form in the first place. If the action that the user selects that leads to the form view is App: open a form to add a new row to this table, then it will always add a new row. Potentially your solution is simply to instead provide the user with an action to open an existing row in the form view for editing. Consider exploring app templates to see how this standard app functionality works.