I’m trying to use an automation to populate a table with values pulled from newly created records in another table. This seems like it should be the most basic function of automations using the “when a record is created” trigger and corresponding “create a new record” action. However, as best I can tell, because Airtable considers a record “created” BEFORE you begin populating it, it will successfully create a new row in the related table, but won’t actually fill it with any value (except the record ID).
I can achieve the desired effect using the “When a record enters view” trigger, which confirms that there isn’t some data type error (and in fact I’ve created rudimentary two-column tables with only single line text to eliminate variables). However, this is a clumsy solution, especially as “when a record is created” is currently one of two possible triggers.
I was about to ask the same question as @ScottWorld. Even if you’re using a record entering a view as the trigger, the specific timing of that trigger may not be when you think it is, and there may be data missing at the time of the trigger that only appears a second or two later after Airtable finishes refreshing things. In other words, what’s sent to the automation is the data in the record at the exact moment it triggers, but some of that data may not be fully refreshed/synced until after the automation has already started.
One alternate way of approaching this is to not pass record data directly into the script via the input variables, but to let the script retrieve the data from the record. Because there’s often a slight delay in launching the script (which you’ve probably noticed during testing), that should let the record data “settle” before the script retrieves it.
Am I missing something? Or is it just that the feature isn’t working correctly.
That depends on your answer to the following: “When do you think Airtable should consider a record ‘created’?” It is not always the case that a record’s fields are supposed to have values for every field from the moment of inception (i.e. a ‘completed date’ field), so how is Airtable to know which fields should have values before the trigger fires?
I agree in the abstract; however, I would think what I’m trying to accomplish is an intended and straightforward application of the built-in automations feature. I want a second table (or multiple tables) to auto-populate with records from a primary table. For example, I want a single content record to populate tables relating to each social media channel.
Also, the visual editor explicitly says you CAN do what I’m describing. I don’t know why they’d design it that way without any warnings if it just wouldn’t work.
*Edit: To be clear/transparent, as someone evaluating this tool for creatives, I can’t imagine a single user finding current automation behavior to be expected behavior. Airtable does know when a user “clicks away” from a record, as it uses this prompt when grouping table record entries (so, when you tag a row it waits for the user to click away before moving it visually to the appropriate grouping). Clearly this would be the more intuitive trigger for “when a record is created,” in the context of a visual editor intended to be used by non-programmers.
That’s precisely what I was asking for (“when should a record be considered created” > “when a user clicks away”). That only would only cover records created from the GUI and not records created
elsewhere (via a form view, Blocks, the API, integrations, etc.), so I imagine the logic would look something like this:
If the automation has never been fired for that record AND the collaborator is “Anonymous”, fire the automation.
If the automation has never been fired for that record AND the collaborator who created that record currently has that record selected, don’t fire the automation.
If the automation has never been fired for that record AND the collaborator who created that record does not have that record selected, fire the automation.
Oh, sorry Kamille — yes, precisely. And thank you, you’ve laid it out very clearly.
I guess what’s perplexing me is that the visual automations editor seems to be encouraging the use of the “when a record is created” as a tool to auto-populate related tables, so much so that I suspect it’s just not working as intended. As a new user I’m very hesitant to say this, but I just can’t fathom why else they would have set up the visual editor this way.
For what it’s worth, I’ve been able to help team members accomplish the kinds of automation they’re looking for using the “when a record comes into view” automation, so this is by no means an insurmountable problem (and in any case I expect more trigger options as Airtable develops this tool).
But, I would love to hear from someone with an inside view on the product if what I’m encountering is effectively a bug.
Well, looks like Airtable just introduced a “when a record is updated” trigger. While this doesn’t exactly answer my question, it does solve the underlying problem. Thanks Airtable.
*Edit: This trigger seems to be suffering from the same issue. When the record is first created, the watched field is considered “update” thereby automatically triggering the creation of a record before any values have been entered.
*Edit 2: In fact this seems to be a systemic issue with automations. Even using the “when record enters view” the same problem – ANY automation with a “create record” action currently creates a blank record when a new record is created in the triggering table. This has to be a bug.
Based on the current way that Airtable automations are triggered, I primarily used the “when a record is created” trigger for form submissions. Those submissions are created with field values as entered by the user. This is particularly useful for automatically linking records when you do not want to expose the list of linked records to users of the form.
In general, I rarely create automations based on user-entered numbers or text strings. I prefer to have a user click a button field once the data entry is complete.
I do find the way Airtable treats record creation and updating in automations to be consistent with how Airtable treats data in other aspects. For example, newly created records in a sorted or filtered view sometimes move or disappear before I can edit them. I’m not condoning this behavior, merely recognizing that it is consistent.
Thaks Kuovonne — that’s helpful (and good to know the forms will work about as expected for our content submissions).
I’ve gotten automations to work as expected using “when … comes into view” triggers, so at least there is a solution. Still, Airtable, if it works “when a record is created” works as Kuovonne describes, the editor should actually reflect this; currently the editor gives you options for that trigger that can’t possibly work without additional scripting (fine for our IT department, less so for a graphic designer).