Is it possible to spawn new tables from the conditions of a record in another table?

[hannah_finch]

Hello all!

I don't believe this is possible with how automations work with Airtable as I know them, as they seem to be restricted to only automating one table and that one table's records. Regardless, I'm hopeful there's an extension or something that can get around this, as this seems like something that would be extremely useful to most people. I'm going to lay out an example for what I'm trying to do/the parameters around it, rather than trying to explain it with a block of paragraphs.

An existing table's records is a list of projects. These projects are labeled as either approved/denied/pending/submitted in this table, and each of the project records were spawned from a submitted form. Once a project is labeled as "approved," it would make my job/my company's job easier if a new table(s) can be spawned, based on pre-saved table templates (though, honestly, I don't even know if it's possible to save a table template). So for example, once a project is labeled "approved," a table labeled as "(project code/name of record) Tasks," another as "(project code/name of record) Expenditures," and so on will appear, with a pre-saved template of each table type as the format. This would be optimal to keep records of other projects separate while it is still ongoing, and then at the end of the project, it could all be either exported as a .csv for archiving or consolidated later. 

So, is this at all possible, or is this just a pipedream? 

[Ben_Young1 · Accepted solution]

Hey @hannah_finch! 

From what I'm understanding, you're creating a new table for each new (approved) project.
Those tables all store task records.

If that understanding is correct, you're going to run into a lot of issues.
While what you're asking for is very much possible, it would be quite difficult and would require a chunky bit of development time.

When something is incredibly difficult to pull off in Airtable, it's generally a red flag that you're approaching something from the wrong angle.
In this case, it seems you're treating Airtable more like a spreadsheet rather than a database.

For this type of workflow, you only need two tables: Projects and Tasks.
That schema looks like this:

This allows you to keep a consolidated, clean, and reliable dataset that scales beautifully.
You can then leverage tools like the Interface Designer to create a really streamlined experience for your users to easily navigate and work with that data.

If you have a set of predetermined, templated task records that need to be created once a project is approved, then you can leverage Airtable's record templates in automations.

Here's a relevant thought and insight that I think is worth meditating on. One of the most common hurdles that I see people struggling to overcome when working with databases and Airtable for the first time is that they don't trust that things will be okay when they start scaling their data. While Airtable doesn't come anywhere near scratching the capabilities of a full blown enterprise database, it only really starts to show its strengths when you start to trust it with larger amounts of data.

If you're confused by anything that I've described or if you'd like a quick demo of what I modeled above, let me know. I'd be happy to toss you a more in-depth example.

[hannah_finch]

Thank you very much for your fast and knowledgeable response!! With this in mind, and after some thinking, I believe I'm going to be restructuring how we have things laid out to better match how Airtable functions. I was thinking of the functionality of Airtable as being a very linear product --> result, and I realize now that Airtable is meant to operate in more of a circular/cycle type of way that works off itself. It makes complete sense now that I think about it like that in such simple terms, but that concept didn't quite click before. Thank you again!