I use prefilled form fields regularly, and when I do, the first field is always prefilled. I don’t recognize the behavior you are experiencing in my forms. Strange that moving it to 2nd place gives you the expected result…
Hey @Ed_Liveikis, are you sure this isn’t only because the cursor jumps to the first field when opening the form? Have you tried selecting another column field and then checking if the pre-filled value in the first field appeared?
The same issue happens on my forms as well, started like some days ago
@M_Schneider yes that’s the case - selecting another field then reveals the pre-filled parameter of the first field. This appears to be a bug however.
Pete, I think this is easily doable. Here’s how I would approach that problem:
- Guests fill out info on form the first time, information flows into table A
- Table A has a formula column that generates a link to a form with the row information pre-filled. The formula would use the Concatenate() formula to generate the link with that row’s information.
- You can send that link as a form to the guest, which would provide them view of their current information. Guest could update their information as needed and the results from that form would flow into a new row in Table A.
- Use duplicate row to highlight duplicates, ideally keyed on email or name.
- Create a view of Table A that returns all rows that are the earliest version of the duplicate rows. This returns the first, or the ‘wrong’ guest information.
- Create a button that deletes all rows in that table.
- Create an automation that runs on some interval and clicks button from Step 6.
Voila! Table A always has the latest guest info, and you have a form that you can send to guests which will let them update information on their own terms.
Sorry to drum up an older post, but I’m following this. I have everything working except the table looking at the dups, how are you determining the earliest version? My main table uses the “Date Created” and “Last Updated” magic fields, but for some reason, those aren’t populated when a form is submitted. It is making me crazy.
You would need to use the .first() formula to go look at the ‘first’ of all matching dupes. Want to embed your doc here and we can work through it together?
I had to make a copy and remove personal data. Hopefully this still makes sense, but the form is not currently attached to this doc. Data sits in Data Warehouse. There is a dup “Annapolis” lost really from there. However, when I did test today, I see that the timestamps were set. So not sure what changed.
See the above. Failed to reply to you.
Hi, I added a new column showing how I’d use the first() formula to return the first matching row for a given Region Name. Is that what you were looking for?
Thank you in advance. Yes, but I am still learning and don’t understand below. Have tried for a couple days now.
“Create a view of Table A that returns all rows that are the earliest version of the duplicate rows. This returns the first, or the ‘wrong’ guest information.”
Hi Carmen, for the view I meant to create a view using a formula that returns the row which matches the information I added with the additional column. So, the formula to return rows for the view would be something like Rowname = duplicaterow.Rowname AND DateCreated = duplicaterow.DateCreated.
If you’re still running into issues I’d recommend sharing a live version of your doc here or reaching out to our support team.
Feature request: update rows via forms!
@BenDavis’s solution is not viable if you have a doc that references rows in the form. You don’t want to delete those rows and add new ones.
I haven’t tried this yet, but you could include a generated id (don’t use
RowID()) as a column in your main table, and have an intermediate table that includes but hides this column in a form (and pre-fill this hidden field when you write the URL). The form would submit to the intermediate table, and you could have an automation that matches the id field to the original table and modifies the corresponding row in the main table. The automation would also want to delete the row from the intermediate table.
I’m going to experiment with this…