My recent posts have covered a variety of use cases for automation. However, in all the commotion of “create documents in the cloud” or “automatically create folders for projects,” I realize there’s a complicated (and critical) step that we’ve never taken the time to address. Specifically: building an automation between multiple tables.
Imagine this example… An application is filled out by a user and you want to update an Airtable database. (If applications don’t apply to your workflow, that’s fine – imagine a similar scenario). The key here is that an outside event occurs and the information must be recorded properly in Airtable. It’s easy enough to build an automation with one action step that fills out this information in a single table. But what do we do when more than one table comes into play? This is precisely the scenario that a form might encourage. Often, a form will include contact information (email, name, etc.) in addition to responses to questions. Are these two sets of data, or one? While there is some ambiguity here, my rule of thumb is to identify them as two sets of data if the following statement is true:
The same ‘x’ can ‘y’ multiple times.
Or in our example, the same contact can submit a form multiple times. So, this suggests to me that our base should consist of at least two sets of data, (1) contacts and (2) forms. Suddenly, we have a more complicated automation to build.
In this video I walk through the steps of building an automation like the one described above. It requires that we use two or more action steps to put data in our database. In addition, it requires that we properly link those sets of data together (don’t we want to see how many times a certain contact has submitted a form?) Without building this multi-step automation, we don’t have the proper linked structure to our data, causing us to lose potential insights from the information we collect.