Custom form is always using MY details and not the user I'm testing with

[Gary_Willmott]

I’m trying to make a form where the user updates their own details, however it’s always updates

I created a custom page, with fields and a button action that “sets column values” of user profile row

however it’s doing the following:

• The fields are always using MY details as default even when I switch user (both are pulling in “Gary Willmott TESTHi v9” as nam)

It’s updating both rows? Mine and the user?

[Jeff_Hager]

Sounds like your “form” is pointing to the first row in the table. What you are actually doing is updating the values in the first row in real time as you type, and then your button is taking those values and setting them in the signed in user’s row. You could just filter the screen to the signed in user and get rid of the button. That would be the simplest solution, but a user would not be able to cancel out of those changes if they chose.

If you are trying to create a form feel, where a user can make changes, but cancel those changes, then it’s more involved. In that case, you should be using separate user specific columns to temporarily hold the values. That’s because every user will be updating the same row. You would then have to write the normal values to those user specific values before showing the screen. Then a user can edit those user specific values. If they choose to save their changes, then the Save/Submit button would take those temporary user specific values and write them to the normal columns in the signed in user’s user profile row.

[Gary_Willmott]

Wow this feels so complicated for updating details

Is there a sample or tutorial on this?

[Darren_Murphy]

Do you have a copy of my custom forms concept App?

How do I create a custom form?

I’m just dropping this here so I have something to refer people to when they ask. This is a simple concept app (copyable), that demonstrates the following techniques: Building custom forms for adding and editing list items (as an alternative to the native forms provided by Glide) Preventing duplicate new entries using User Specific Columns and Relations Enforcing mandatory input items The use of visibility conditions and user specific booleans to control user flow There is nothing particula…

You can study that to see how it works.

I’m not aware of any video tutorial, maybe I’ll make one and add it to that post when I can find some time.

[Gary_Willmott]

Hi Darren,

I tried sample Multi-Step Form, which uses user specific columns and relations, however it looks like it adds rows

I went through this thread and it looks like it’s going in circles? I don’t understand why such simple functionality is so complicated?

All I’m wanting todo is get the user to update specific data about themselves, without going through the loop of having to edit their profile?

Is there no sample template around that can demonstrate this?

[Darren_Murphy]

I’ll have a look at this later when I look at that other issue.

[Darren_Murphy]

@Gary_Willmott - I just had a look at this one.

The issue is that you have no filter on that screen, so it’s attached to the first row in the User Profiles table, which happens to be yours. And because all the screen entry components are writing directly to the column values, as soon as you start changing any values they change in your row - no matter which user you are logged in/viewing as.

The onSubmit action that you have is working in the sense that it is updating the correct row. But at that point it is too late because values have already been changed in the first row.

One way to fix that would be to apply Row Owners to the email column in your User Profiles table, then the screen would automatically filter to the signed-in user row. But this could introduce other complexities that you may not be ready to deal with yet.

So the next best option will be to apply a filter to that screen, as follows:

With that in place, your onSubmit action becomes redundant, and is no longer required.
I made a copy of your App and applied the change, so you can see and test it for yourself there.

Worth noting that @Jeff_Hager’s initial diagnosis was spot on:

@Jeff_Hager

Sounds like your “form” is pointing to the first row in the table. What you are actually doing is updating the values in the first row in real time as you type, and then your button is taking those values and setting them in the signed in user’s row. You could just filter the screen to the signed in user and get rid of the button. That would be the simplest solution, but a user would not be able to cancel out of those changes if they chose.

As were his additional comments:

@Jeff_Hager

If you are trying to create a form feel, where a user can make changes, but cancel those changes, then it’s more involved. In that case, you should be using separate user specific columns to temporarily hold the values. That’s because every user will be updating the same row. You would then have to write the normal values to those user specific values before showing the screen. Then a user can edit those user specific values. If they choose to save their changes, then the Save/Submit button would take those temporary user specific values and write them to the normal columns in the signed in user’s user profile row.

[Gary_Willmott]

@Jeff_Hager

Sounds like your “form” is pointing to the first row in the table. What you are actually doing is updating the values in the first row in real time as you type, and then your button is taking those values and setting them in the signed in user’s row. You could just filter the screen to the signed in user and get rid of the button. That would be the simplest solution, but a user would not be able to cancel out of those changes if they chose.

Thanks for taking the time on this @Darren_Murphy
I miss read @Jeff_Hager 's answer and this makes complete sense now, I guess I just need to see it visually