Re: How to create publication dates for different content platforms and look up in date field
Hi David, thanks for the video! I have a very clear understanding of what we’re trying to achieve now.
Just so we’re on the same page, it appears we’ve successfully solved the issue where we limit the dates appropriately for each platform, and we are now trying to solve the issue of allowing users to modify previously entered data.
I am assuming the limitation we’re facing is that not all of the users will be collaborators in the base, and thus we need them to be able to make edits via Forms instead of via the table itself.
Unfortunately, we are unable to edit records via a Form.
However, there are workarounds for this, and they all basically involve us having two tables, one of Form submissions (let’s call this “Form Submissions”, and the other of formatted data (“Data”) compiled from “Form Submissions”
Users would use one form to create records in “Data” and to modify records in “Data” they would fill out a form that would create records in “Form Submissions”
From here, we have some options:
- Users are given a form where they can select the record from “Data” they would like to modify, and submit the new data they’d like to use to replace it, and we use rollups and lookups to handle data formatting
The pitfalls of this method would be that your users wouldn’t have a good experience trying to find the record they need to edit, they would not be able to see the record’s current data, and they would have to fill in all the fields that the record previously had filled, not just the one they want to modify. Consider: They just want to modify the “Blog Date” field, but they also have to ensure that the “Platform 1 Date” field is also filled in with the previously set value
- Users are given a form where they can select the record from “Data” they would like to modify, and submit the new data they’d like to use to replace it, and we use scripting to handle the data formatting
The pitfalls are similar to the previous option, except that users will not need to fill in all the previously set values, and also you would have to maintain a script
- Users are given a shared view where they can see all of the records in “Data”, and are able to click a button (maybe “Edit Record”) that would open a pre-filled form, and we use rollups and lookups to handle the data formatting.
The pitfalls of this option are that your users would be able to see all of the records in “Data”, and I’m unclear whether we’re not letting users modify stuff on the table directly due to them not being allowed to see the data or them not being collaborators. Personally, I think this is the nicest one and recommend it
I’ve created option 3 for you here. You can duplicate the base via clicking the title of the base and then the three horizontal dots.
Even without duplicating it, you can test it out by going to this shared view link. When you click “Edit Record”, a new window will open with a Form prefilled with the record’s current data and the record automatically linked. All the user will have to do is modify the specific field they need to change.
On submission, the “Data” table will update automatically.
Here’s a gif of it working:
Let me know if you have any questions or if you would like to explore option 1 or 2
Roger that
Hmm, in your CSV, is the data in the Platform column comma separated? So with reference to 7 great TED Talks to watch to while you’re studying AAT, is the text in the Platform column the following?
AAT, Comment
If it is (or if it isn’t but you can make it export like that), then we could just convert it into a linked field instead of having to resort to automations
