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.
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: