Accessing Created At or Updated At Column in Formula Editor

Ian M. · 2024-01-17 04:17:21.370608+00

How do you "get to" the Created At or Updated At col in the formula editor?

Accessing Created At or Updated At Column in Formula Editor | Clay

4 comments

· Sorted by Oldest

Clay Team
APP
·
·
Currently that isn't possible (just tried a few things myself), but I have submitted this as feedback to see what is possible to do here. What is the end goal you're trying to accomplish by using these inside the formula editor?
Stefan K.
·
·
Update: This is intentionally not available, as it created problems for a lot of people, when it created infinite loops in their tables (and wasted their credits) because they would bind the "updated at" field as an input to their integration columns; so the integration cell would run, then the row would get updated with the new integration cell data, and change the updated_at value, then the integration cell would detect that one of the inputs changed (the updated_at value) and re-run, etc... so we decided to disable the usage of these 2 fields altogether
Ian M.
·
·
let me see if I understand. At the moment, a col eg Col D which as a dependency on Col A can detect in there is a change in A, and that triggers it to re-run. (Question: Does this happen in the background, 24x7, even when the table is not open, I'm not logged in? I can see that this MIGHT be wanted by the user, so that when they open a table, the data is current). I can see why this might NOT be wanted, as I might only have some "production" tables and many other tables which I dont want/need things to be kept up-to-date. Maybe we need the concept of "Production" mode on tables?? If you expose Updated At to the formula editor, there is a possibility of a loop because logic triggers a run, which changes the state that of a precedent cell, which triggers a run .. wash-rise-repeat. Surely this can be avoided by creating a new enrichment "Time Trigger" (which uses but does not expose the Created/Updated At), which has a flag that suppresses/breaks any potential loops?
Clay Team
APP
·
·
Yep, that's something the team will likely introduce if the concept/idea of scheduled runs is landed (no ETA yet) but in any case, if a field changes and your tables are set to auto-update then any dependencies should run to stay fresh if needed even if you step away. This is how some users have set up their automated workflows via webhooks and automated exports, almost 0 extra manual work is required if it's set up as they need it to be.Of course, you can still print and use a "created at" date value with the formula generator, making that value dependent on another column/value. Just the functionality of a continuous "updated_at" field is what would likely cause major performance issues or be abused to create loops, thus that concept/field is not currently enabled in any way.

Clay Team
APP
·
·
Currently that isn't possible (just tried a few things myself), but I have submitted this as feedback to see what is possible to do here. What is the end goal you're trying to accomplish by using these inside the formula editor?
Stefan K.
·
·
Update: This is intentionally not available, as it created problems for a lot of people, when it created infinite loops in their tables (and wasted their credits) because they would bind the "updated at" field as an input to their integration columns; so the integration cell would run, then the row would get updated with the new integration cell data, and change the updated_at value, then the integration cell would detect that one of the inputs changed (the updated_at value) and re-run, etc... so we decided to disable the usage of these 2 fields altogether
Ian M.
·
·
let me see if I understand. At the moment, a col eg Col D which as a dependency on Col A can detect in there is a change in A, and that triggers it to re-run. (Question: Does this happen in the background, 24x7, even when the table is not open, I'm not logged in? I can see that this MIGHT be wanted by the user, so that when they open a table, the data is current). I can see why this might NOT be wanted, as I might only have some "production" tables and many other tables which I dont want/need things to be kept up-to-date. Maybe we need the concept of "Production" mode on tables?? If you expose Updated At to the formula editor, there is a possibility of a loop because logic triggers a run, which changes the state that of a precedent cell, which triggers a run .. wash-rise-repeat. Surely this can be avoided by creating a new enrichment "Time Trigger" (which uses but does not expose the Created/Updated At), which has a flag that suppresses/breaks any potential loops?
Clay Team
APP
·
·
Yep, that's something the team will likely introduce if the concept/idea of scheduled runs is landed (no ETA yet) but in any case, if a field changes and your tables are set to auto-update then any dependencies should run to stay fresh if needed even if you step away. This is how some users have set up their automated workflows via webhooks and automated exports, almost 0 extra manual work is required if it's set up as they need it to be.Of course, you can still print and use a "created at" date value with the formula generator, making that value dependent on another column/value. Just the functionality of a continuous "updated_at" field is what would likely cause major performance issues or be abused to create loops, thus that concept/field is not currently enabled in any way.