# Calling NOW() multiple times in the same formula **URL:** \ **Category:** Airtable Questions\ **Created:** [June 8, 2023, 2:59pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659 "2023-06-08T14:59:07Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![julian.post](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/julian.post/32/1032_2.png) [@julian.post](https://air.tableforums.com/u/julian.post)\ **Post date:** [June 8, 2023, 8:29pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/22 "2023-06-08T20:29:35Z")
> [@bfrench](#): > > The Enterprise events API does support that definition, making it possible to trigger a webhook when, and only when, the timing is not in question; the record has been changed and committed. Gotcha. So, from the user/editor’s perspective, and they’re editing a single line text field, this is when they click away from the cell? ---
**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\ **Post date:** [June 8, 2023, 9:06pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/23 "2023-06-08T21:06:58Z")
> [@bfrench](#): > > I assume you are jousting with the definition of a fully changed field - i.e., a field that was changed and committed such that no more changes are being typed, right? It’s a timing issue and it’s because Airtable doesn’t expose a method for knowing the field edit has been committed. I think it is an issue of not knowing when the user is done typing. It is possible for Airtable to fully commit text changes, but how can Airtable know when a user is really done typing? Airtable can know when the focus leaves the control, at which point the user is probably done typing. But sometimes I’m still typing in a text box and I change the focus because I want to momentarily put my attention somewhere else, even though I’m not done typing. ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 8, 2023, 9:29pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/24 "2023-06-08T21:29:18Z")
> [@julian.post](#): > > this is when they click away from the cell? Yes, but there are many aspects to the event handler that triggers based on certain conditions. ![CleanShot 2023-06-08 at 15.24.38@2x](https://canada1.discourse-cdn.com/flex029/uploads/tableforums/original/1X/7623947e66ed92b7465abc5395c8bca4d2672716.jpeg) > [@Kuovonne](#): > > I think it is an issue of not knowing when the user is done typing. It is possible for Airtable to fully commit text changes, but how can Airtable know when a user is really done typing? I think the enterprise webhooks do know when to fire the “done typing” events. Certainly with greater precision than a formula could measure. > [@Kuovonne](#): > > But sometimes I’m still typing in a text box and I change the focus because I want to momentarily put my attention somewhere else, even though I’m not done typing. This would cause the event handler to fire two times. But that’s a common aspect of programming with any webhook system. You must create webhook listeners that act favorably to such occurrences. ---
**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\ **Post date:** [June 8, 2023, 9:40pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/25 "2023-06-08T21:40:50Z")
> [@bfrench](#): > > This would cause the event handler to fire two times. But that’s my point. The event handler saying that text has changed fires for each “chunk” of text, but the “chunks” don’t really correspond to when the user is done typing. For example, automations that check for the presence of text in a field fire as soon as the user starts typing. This is because that first character or first few characters are already committed. When people type slowly, the automation triggers with only the first character, but if someone types fast, the automation might contain multiple characters. If someone triggers the automation for when the field changes, it will fire multiple times before the user stops actually typing for real. ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 8, 2023, 10:52pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/26 "2023-06-08T22:52:22Z")
> [@Kuovonne](#): > > it will fire multiple times before the user stops actually typing for real. Have you used enterprise webhooks? Or, are you speaking purely about the trigger behaviors in Airtable itself? ---
**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\ **Post date:** [June 9, 2023, 2:39pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/27 "2023-06-09T14:39:04Z")
> [@bfrench](#): > > Have you used enterprise webhooks? No. But I have read the documentation and nothing I’ve read implies that enterprise webhooks can know when a user is done typing based on my idea of when a user is done typing. (Which might be different from your idea of when a user is done typing. My idea of when a user is done typing is highly colored by the idea of a parent working from home who gets interrupted mid-sentence by a child.) I am thinking that knowing when a human is done typing is an incredibly difficult task. There are proxies like when the focus moves from a control or when a certain amount of time passes without additional input. But while these may be good enough for most cases, they are not guarantees that the user is actually done typing. Plus the idea of using enterprise webhooks for Julian’s use case seems extreme. In order to use enterprise webhooks you have to set up a system to receive the webhook, register the webhook, manage refresh tokens, go back and ask for the payload, and so much more. Not to mention being limited to only ten webhooks per base, and two webhooks per connection. Way too much work to send a slack notification. ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 9, 2023, 3:13pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/28 "2023-06-09T15:13:50Z")
> [@Kuovonne](#): > > No. But I have read the documentation and nothing I’ve read implies that enterprise webhooks can know when a user is done typing … I recommend a few tests to compare how each performs. My experience is that enterprise webhooks possess some magic that does not exist in other event handlers of the Airtable platform. Events are notoriously ambiguous about the conditions that trigger them. I get the sense that Airtable Proper is weak, and Airtable Enterprise is an industrial version of the weak stuff made available to all paying customers. Ambiguity in webhooks will always be there, so developers building truly real-time systems must also craft a deep sensitivity to webhook events that maybe should be ignored. A good example is the Copper CRM system. It generates webhooks concerning object changes without deference to field completion. I overcame this in one project by using AI embeddings to test if the data was likely complete. Embeddings, as you know, are blistering fast vectors that can definitively tell you if the data is similar to a learner shot. If not, the score is low, and the event should be rejected from further automation processing. This is just one example of mitigating poorly-designed outbound event webhook systems. ---
**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\ **Post date:** [June 9, 2023, 3:25pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/29 "2023-06-09T15:25:28Z")
> [@bfrench](#): > > Airtable Enterprise is an industrial version of the weak stuff made available to all paying customers. This is both really cool that a more robust version exists, and sad that it is gated to enterprise. ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 9, 2023, 3:59pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/30 "2023-06-09T15:59:12Z")
> [@Kuovonne](#): > > sad that it is gated to enterprise. Agree. This aspect of the APIs should be common to their entire offering. So few working in Airtable Proper will utilize this that it will have little impact on the service. In fact, it would probably free up resources and this policy demonstrates why Airtable is out of touch with their customer base. ---
**Author:** ![ScottWorld](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/scottworld/32/5_2.png) [@ScottWorld](https://air.tableforums.com/u/ScottWorld)\ **Post date:** [June 9, 2023, 4:15pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/31 "2023-06-09T16:15:58Z")
One of my Top 20 Biggest Shocks™️ when switching from being a Certified FileMaker Developer to an Airtable Consultant was that Airtable didn’t natively understand the concept of “committing records”. This concept is built into every single layer of the entire FileMaker platform, and can be programmatically controlled as well. ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 10, 2023, 11:27am UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/32 "2023-06-10T11:27:32Z")
The commit concept is a fundamental tenet of transactional processing. Without it, you have no ability to roll back transactions in the event of dependency update failures. This leads to fractured relationships, orphaned children, etc. But it’s a rare case that any no-code enthusiasts would need to know if changes are actually committed, or to care much about the tenuous nature of transactional processing. However, suddenly no-coders care as soon as they are handed a new construct - _automations based on record changes_. Now they care about “commits” without actually knowing why. So they throw other crap (like NOW()) at the problem, and this makes it worse. I believe the Enterprise events API was developed many years after the other APIs and may contain a better notion of optimistic committed changes. Perhaps there is an element of pessimistic commits baked into the algorithm. ---
**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\ **Post date:** [June 10, 2023, 12:49pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/33 "2023-06-10T12:49:16Z")
> [@bfrench](#): > > The commit concept is a fundamental tenet of transactional processing. I understand that transactions as complete units are important. I still don’t see how the concept of a commit relates to knowing when a user is done typing. Knowing when a user is done is such a tricky matter. For example, when typing a reply on this forum, I may put down and pick up my phone multiple times. I switch to different tabs in my browser. But the forum still needs me to press a button to say when I am done typing. I am totally willling to believe that the enterprise events api does a better job of grouping typing sessions than automations. The record history log seems to do a decent job of deciding which characters were changed together, but that predates the enterprise events api, and sometimes groups changes in ways that hide conditions that could trigger automations. ---
**Author:** ![ScottWorld](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/scottworld/32/5_2.png) [@ScottWorld](https://air.tableforums.com/u/ScottWorld)\ **Post date:** [June 10, 2023, 1:49pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/34 "2023-06-10T13:49:34Z")
Similar to what @kuovonne mentioned above, in FileMaker, the user would indicate that they are done typing by clicking anywhere on the screen that is OUTSIDE of the field. The click of the mouse indicated a commit. So it did require manual user intervention. (However, the commits could also be controlled programmatically by the developer as well, because we could monitor users’ keystrokes and other behaviors.) ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 10, 2023, 3:10pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/35 "2023-06-10T15:10:50Z")
> [@Kuovonne](#): > > But the forum still needs me to press a button to say when I am done typing. Precisely. There is no such corollary action in Airtable. As such, it (a) assumes everything is saved as you change fields, and (b) must use an optimistic commit assertion. Similar constructs exist with regard to record locking. > **[Optimistic concurrency control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control)** > > Optimistic concurrency control (OCC), also known as optimistic locking, is a concurrency control method applied to transactional systems such as relational database management systems and software transactional memory. OCC assumes that multiple transactions can frequently complete without interfering with each other. While running, transactions use data resources without acquiring locks on those resources. Before committing, each transaction verifies that no other transaction has modified the dat... ---
**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\ **Post date:** [June 10, 2023, 4:18pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/36 "2023-06-10T16:18:33Z")
> [@bfrench](#): > > As such, it (a) assumes everything is saved as you change fields Huh? Airtable saves changes before you change fields. I can be typing along in a field with my cursor staying in that field, and formulas recalculate, automations trigger, and other users on other computers see what I have typed. Those changes have to be saved before I change fields in order for all those things happen. ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 10, 2023, 4:28pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/37 "2023-06-10T16:28:28Z")
> [@Kuovonne](#): > > Airtable saves changes before you change fields I think we’re saying the same thing. There is no “save” button for changes to Airtable fields, right? ---
**Author:** ![Kuovonne](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/kuovonne/32/17_2.png) [@Kuovonne](https://air.tableforums.com/u/Kuovonne)\ **Post date:** [June 10, 2023, 5:59pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/38 "2023-06-10T17:59:42Z")
> [@bfrench](#): > > There is no “save” button for changes to Airtable fields, right? Correct (except for forms). But I though you said that Airtable saves **as** you change fields, and I think it saves as you type. Not necessarily with every key press (although it may seem that way), but also well before the human thinks typing is complete. ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 11, 2023, 1:38am UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/39 "2023-06-11T01:38:03Z")
> [@Kuovonne](#): > > Correct (except for forms). And the API, and scripts (I think). > [@Kuovonne](#): > > it saves as you type. Perhaps, but that’s irrelevant. It uses an internal mechanism that ambiguates the definition of a commit. And with that, triggers in automations are equally ambiguous. One might conclude that commits are optimistic - i.e., they have a wide range of possibilities in the no-code features. I believe Enterprise events (as interpreted by the Enterprise API) lean toward pessimistic commit behaviors. As such, anyone trying to build precise automations may have far better luck creating webhooks to sense data modifications. I have created outbound webhooks that have worked really well. This is why I believe the event handlers used by the Enterprise API are not the same event handlers implemented in the no-code client. ---
**Author:** ![ScottWorld](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/scottworld/32/5_2.png) [@ScottWorld](https://air.tableforums.com/u/ScottWorld)\ **Post date:** [June 14, 2023, 5:30pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/40 "2023-06-14T17:30:47Z")
@bfrench @Kuovonne Based on this user’s problem with Airtable’s Enterprise webhooks, it doesn’t seem like the behavior is any different with Airtable’s webhooks: > **[Webhook gets triggered on every character entered in a field](https://community.airtable.com/t5/development-apis/webhook-gets-triggered-on-every-character-entered-in-a-field/td-p/156422)** > > I have a webhook set up where it is watching single field in one table. The issue is that the webhook gets triggered on every single character entered/deleted. The expected default behavior is that the webhook gets only triggered when the user is... ---
**Author:** ![bfrench](https://yyz1.discourse-cdn.com/flex029/user_avatar/air.tableforums.com/bfrench/32/46_2.png) [@bfrench](https://air.tableforums.com/u/bfrench)\ **Post date:** [June 14, 2023, 6:16pm UTC](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659/41 "2023-06-14T18:16:38Z")
This post in the Khoros community is from someone who has not read the [documentation](https://airtable.com/developers/web/api/webhooks-overview). Developers who are unaccustomed to the basic premise of a webhook need to know that the hook is designed to be a notification of the change, not the actual changed value. > When a change that matches the webhook’s specification occurs, we send a notification via a POST request to the relevant webhook’s notification URL containing the base ID and the webhook ID. The client (your webhook listener) is obligated to intelligently unpack the notification payload and use it (and following notifications) to understand the nature of the change. > The recipient of this request should respond with an HTTP 200 or 204 status code and an empty response body. After successful delivery, the recipient of this notification is then responsible for requesting the contents of the updates from the API (using [list webhook payloads](https://airtable.com/developers/web/api/list-webhook-payloads)) in a separate HTTP request. I could be wrong, but I don’t get the sense that this user is doing this. I think he’s assuming a webhook POST is a one-and-done proposition. > [@ScottWorld](#): > > it doesn’t seem like the behavior is any different with Airtable’s webhooks: Well, it is different because, unlike the events in the client, the Enterprise API sends all sorts of information useful to understanding the likelihood that a field edit has been completed. As a developer, it’s your duty to build a listener that takes advantage of this added stream of data. [Previous page](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659.md?page=1) [Next page](https://air.tableforums.com/t/calling-now-multiple-times-in-the-same-formula/659.md?page=3)