Is there a way to identify/track which user made a particular edit? Back on Airtable, the activity tracking reflects “You edited this record via API”, which is true, but I was wondering if there was any way I can link the edit to the logged-in user? I have a users table in my base, and users in Softr are linked to Airtable. Is the user information passed to Airtable with the edit?
I would try to do with with a hidden field in the form whose value is set to the current logged in user, and this form field would be mapped to a lastEditedBy field in the Airtable record. See the docs for how to set up the hidden field.
Hi David. Was he referring to a form or the editor? Please let me know how your suggestion would work, no-code, since Softr forms create rather than edit existing records.
Was just asking about something like this over here:
I assumed he was referring to the editor. This suggestion was off the top of my head - I didn’t actually try it. Did you try it? Did you get stuck somewhere or did it not work?
1 Like
I think he was referring more to editing using permissions and identifying a change made by a user with permissions to edit a record.
I like your idea of using a Softr form to update an existing record with a logged in user’s info though. It would work, if only Softr forms could not only create new records, but identify and edit or update existing records. I did what you suggested recently, overlooking the fact that forms only create new records, thinking this would be a great solution.
If they could, Softr would be a lot more powerful, especially for no-coders!
1 Like
Yep I forgot that too. Waiting for Forms 2.0…
Apparently it’s not planned for 2.0 according to the link I sent earlier.
Have you already looked into the possibility of building this functionality into the Airtable record editor?
No. Would that be seamless for users of a Softr web app?
No, it would be fairly seamful. But right now this is a common pattern: use the Softr form to create the record, then use the Airtable form to edit it.
1 Like
Do you mean that a Softr end-user would somehow link to an Airtable form? If so, how would the relevant existing record be identified in Airtable, then updated with the Airtable form?
Thanks for your original reply dcolletta - I didn’t see that at the time. My original meaning was that I was letting the front-end user edit the record directly via permissions (there’s 6 fields in a record they can change) but that if a dodgy edit was made, I couldn’t trace it back. I hadn’t thought to employ a form for that - but as you say, if I did I could insert the hidden user field. Will give it a try. Thanks Ben for bumping the topic!
Sure thing. Good luck attempting to update an existing record with a Softr form though. If you figure it out, let us know.
No, I just came back to say that I couldn’t get it to work. I’m not sure a form option would allow me to display the existing content that the user is supposed to be editing, so I don’t think it will work for my purposes. Love to hear if anyone has any other ideas.
I was wondering the same thing, how could I know what user edited a record via softr edit record modal.
If I understand correctly, the modal popup for edit records doesn’t log, {LOGGED_IN_USER:EMAIL}, so you can not map it to any field.
This approach is not that complicated,
You will simply create 2 things: a new record via form, taking care of logging the id of the record that you plan to edit or update, and a new table on airtable to host these submissions.
Then when this records gets created it will fire an automation that will look up the record id on your main table, and replace content with the one you entered via softr form
That sounds like a good option for some uses acjnas. My users aren’t replacing content though, they’re editing long text fields in a list details block. Unless I can prepopulate the form with the exisiting field content somehow? Haven’t looked into that…
I have an automation going the other way - when each edit it made on the primary table, the automation adds it to an edit table for review. The answer for me would be your first suggestion - the edit modal needs to log {LOGGED_IN_USER:EMAIL}. Maybe I’ll log a feature request.
Have added a feature request here: Pass {LOGGED_IN_USER:EMAIL} to Airtable when edit made by user.
1 Like