Knowing when to trigger an automation for typed values can be tricky.
Source of confusion
When does a field go from not having a value to having a value? When is a field considered to be updated? How people answer to these questions tend to be different from how Airtable answers these questions.
People tends to think that the change occurs when they are done typing, often represented by a change in focus from the cell or record in question. However, Airtable considers a text field to have a value as soon as the first character is typed. Airtable considers the field to be updated with each additional key stroke (although in some cases, Airtable batches multiple keystrokes together).
Affected fields
This issue most often affects the following field types:
Text fields (single line text, long text, and rich text)
Number fields (number, percent, currency, etc.)
Date fields (date and date/time fields, except for date-only fields when users only use a date picker)
This issue can also affect the following field types, but issues are not as common:
multiple select fields
linked record fields
multiple user fields
This issue does not affect the following field types:
checkbox fields
single select fields
rating fields
single user fields
Common mistakes
Things to NOT do:
Triggering an automation with the condition of a field having a value, and expecting the full value typed by the user. The result is usually just a small portion of what the user typed.
Triggering an automation for when a typed field is updated. The result is usually multiple automation runs for each character typed.
Triggering an automation based on a formula field that compares NOW() with the LAST_MODIFIED_TIME() of the editable field in question. The results of NOW() can be wildly inaccurate and the formula itself is resource intensive, which can slow down a base.
Alternatives for “when field has a value”
Have users manually indicate when they are done typing by selecting a checkbox or single select field. If the user is using an interface, have the user push a button. This requires user training and trusting that users will follow that training.
Restrict data entry to forms, such as interface forms. However, this can be difficult when you want quick editing of existing records, as native forms currently cannot edit existing records.
Use the “when field has a value” trigger, but introduce a pause in the automation via scripting, followed by a fresh read of the value. You still run the risk of the data entry being incomplete after the pause.
If your automation is a notification, use the “when field has a value” trigger, but do not include the actual value in your notification. Instead, have the notification say that there is an update, but direct the user back to Airtable for the actual message.
Some combination of the above.
Alternatives for “when field is updated”
Have users manually indicate when they are done typing by selecting a checkbox or single select field. If the user is using an interface, have the user push a button. This requires user training and trusting that users will follow that training.
Have a hidden helper field that stores the “previous” value of the field via automation. Have a formula that compares the “previous” value with the current value to determine when there is an update. Include a pause in the automation (via scripting), a fresh read of the new value, and an update of the “previous” value. You still run the risk of the data entry being incomplete after the pause. This system also runs a risk of not catching additional updates if there are changes after fresh read but before the automation finishes.