At the moment the form only allows input of new data. Can we have a form for editing existing records? At the moment we can only edit in the table meaning I can’t present the records the way I want. Can’t even hide columns on mobile, meaning the users are free to wreak havoc on the existing data :grinning_face_with_smiling_eyes:
This would be really really helpful, and pretty much essential to how I’m using Airtable so far!
I’m sure it’s not an easy thing to implement. But some sort of view, maybe where a user can see all the records they’ve created (or been assigned to) so they can click one and make changes, but only those records and not the entire table (or base).
Right now, I have a table of agents I can assign to client records via a select column, it would be awesome if whichever agent(s) I selected in that column were the only agents who could access/edit those respective records via said form view.
Again, really great work here, just a few more tweaks and this will be the perfect platform. It’s so close already.
Same here. I’m setting up a database for a project and want to share ‘editable’ existing records to certain users. A suggestion - within a particular record view (admin), there’s a share link. Anyone with this private link can view and edit only that record, nothing else. Better yet, records can be grouped. And particular groups of record can have share link to allow particular users to edit records within the group only.
Flexible sharing capabilities and user access control will make Airtable a truly powerful collaborative database platform.
Yes, basically a customized “Expanded View” is greatly needed for editing individual record data without the clutter that is presently displayed in the existing expanded view.
I’m with you all. I would like to see permissions set to the “view” level so that I can allow some semi-power users the ability to update, without seeing certain sensitive columns. Permissions could do this, or as this thread suggests, I could let them edit with this editable form!
As with all other feature requests, the most useful and effective way to help us prioritize this feature is to provide highly detailed, specific examples of how you would actually use this feature. We’d love to hear not only abstract descriptions of the functionality you want, but actual stories about the real people who will use it, the actual nature of the content on which you’d be collaborating, etc. This is especially helpful for features like this one, where there are many different ways we can implement it, each addressing a different subset of scenarios.
I can give you more feedback as to my particular situation, I am using it for a Church Member Roster tool. I will tell you, what Airtables has blows other products out of the water when it comes to this type of tool and I have been able to build a pretty good setup. We’re not fully implemented but I believe it is going to greatly help the Elders make sure that they are accounting for all members. And I believe this is a tool that many, many other churches may be interested in.
In particular, I have a “roster” table, but then a second table with “elder notes”. The elder notes could potentially house sensitive information that is only for the elders to share among themselves. That being said, we have staff members who we would like to be able to update member information, without seeing the full blown table.
My thoughts on a solution for this was to extend privilege levels down to the “table view”, not just the “team” or particular “base”. However, the idea presented here, with an editable (and searchable) form, would allow for us to give staff members an ability to look up particular records and edit only what is on the form, not the whole table, and therefore not see the potentially sensitive information. They are already using a form to add new records, but it would be good for them to be able to edit them also.
Here is a specific use case that I would use this for…
Implementing an RFQ (request for quote) module that contains the following tables…
-Supplier Details
-Supplier Contact Details
-Item Detail (description, type, material, special requirements, customer name, project name)
-Item Revision Details
-RFQ Header (supplier name, date, rfq comments, etc)
-RFQ Detail (quantities per line item, comments per line, etc)
-RFQ Detail Responses (prices per quantity, lead times, deviations, etc)
A lead buyer or planner would create a new RFQ, containing the RFQ Header and RFQ Details, and submit to the procurement team to obtain quotes and those buyers would then populate sets of RFQ Detail Responses from suppliers. They would have access to a form that allowed them to add and edit responses to the RFQ. The lead buyer would be able to review the results from all of the other buyers at any time, using his own view (form) that display the same data with different grouping and emphasis (grouped by part number, sorted by price, displaying supplier name, lead time and comments next to each)
This is just one example. I can think of a hundred manufacturing cases like this.
Here is another manufacturing case. A quality control module focused on gathering and analyzing NCMR events (non-conforming material reports), using the following tables…
-NCMR Detail (date, part number, cause code, supplier, report originator, comments, disposition)
-Inspection Records Header (date, part, supplier, lot size, comments)
-Inspection Record Details (sample size, requirement, result, pass or fail)
-Supplier Detail (supplier name, address, primary phone, primary contact, last evaluated date, certifications, quality performance rating, on time delivery rating, primary account manager, etc)
-Contact Detail (contact name, title, direct phone, notes, etc)
-Item Detail (part number, date created, engineer name, current revision level
-Item Revision History (revision level, revision date, ECO number)
-PO Header (supplier name, order date, etc)
-PO Detail (line item qty, part number, due date, etc)
These can be combined to create powerful tools for quality and purchasing to work together on gathering and analyzing supplier quality performance. For example, a quality manager may have a custom view that lists items in descending order by number of NCMR events compared to number of line items delivered, and other which emphasizes quantity of rejected items compared to total number ordered (in a given time period, which is an unbound field that is used purely for calculation and is not stored in a table). The quality manager would then flag items that he wants improved based on these results, and submit the report to the purchasing manager. The purchasing manager would also have various custom views which list suppliers descending by total annual spend, with a corresponding quality rating and last evaluated date next to that information.
Quality department employees could write NCMR’s against suppliers, buyers could gather responses to those NCMR’s and the department managers could review summaries or individual reports based on the data gathered.
