It might help to explain why you want this process which ostensibly uses a table as a record. If the form is submitted 100 times are you expecting there to be 100 tables, each with one record?
Thanks Bill! yes that’s correct, the idea is that we are creating a pre-filled out Scope of Work document like the one attached below. So each record would include data that would then fill out the SOW doc (table). So if the user says they are designing 3 pages of a website, we will add ‘3’ to the total number of pages in SOW doc. Does that make sense?
Yep - this visual helps, but there’s a level of awkwardness here because most use cases involving Airtable tend to focus on its strengths more from a database perspective and less from a spreadsheet (or document) perspective.
Given that each phase and phase elements are on the (y) axis, with values on the (x) axis, some people might conclude that you have this design on a pivot and the phase elements are really fields. But I get it, this is a well organized approach given your objectives. It would be helpful to see what the column names are as well.
In any case, using a table to simulate (or mimick) a “document” is not unreasonable unless, of course, at scale this won’t work. Can you describe the number of anticipated documents you plan to create?
Also, describe the users of these documents - will they each have Airtable accounts and edit this data directly?
Better stated - part 3 seems to be where your requirements are not easily met given that each form entry is the equivalent of a table.
Vastly, forms generally create records, not tables. Your specific need to create separate tables for every form entry is a significant departure from the usual and customary forms -> database processes. And one must at least ponder how a single form entry will be able to generate a dozen or so records in a table. Certainly, a script action can do this, but I’m unsure if you’re really looking for a no-code solution.
My understanding is that the only way to create a new table with code is to use a custom app. And even then, only simple field types can be created. Plus, all the tables would exist in the same base, which creates problems when you want to deliver these tables to different customers.
