A Time Based Automation
to delete checked rows older than 30 days
In the community a question came up expressing a feeling many makers might have had one day. Are we sure we want to take the risk to have all rows deleted while we only intent to have some removed?
Evaluate all rows
Automations run over every row of the defined table(s), but do not run their instructions (like deletete thisRow
) on every row. In order to understand where to execute the instruction, the automation simple checks everything before running.
When does an automation run?
An automation runs when you tell it to run. It runs when the doc is closed and when you are not behind your computer, when you machine felt asleep and is getting cold. It works independently from you and it does the job for you. The maker instructs, the automation executes.
KISS
In my community response I focused on simplicity. You need a rule that tells when a row is ready to be deleted. The rules I created are — once you seen them — simple: the checkbox should be checked and the modification moment should be 30 days or longer ago.
Delete this row — condition
To keep it simple I added a checkbox in the table, although I could have written a more complex function to avoid this support column. Better clear than clever in my perspective. In our example the checkbox had to be checked and the check should at least be 30 days ago. Two conditions and one action.
The checked is the easiest and the 30 days ago is always related to the day of today, expressed in Coda as Today(). In the example below I took one day instead of 30 days, but the logic is the same:
The automation
Every automation has at least two parts. First we define when an automation should run, second we tell what to do. In the community I presented a time based solution since this is the only one that can workin this context. A change of a column only works when you manually can edit the value. This type of automation does not work with a function behind it.
We ask the automation to run every day at 09:00 AM (but it can be any time). When it is running it should delete rows that meet the condition cbDeleted
is checked and this we write as above. Only the name of the column, no need for cbDelete = true
or cbDelete.Contains(“true”)
.
And this is it. The doc below shows you how it looks like:
Can it be done differently? Of course. The suggestion of Quentin_Morel shows another path. His solution evaluates each row via a function. It works well. The Quentin_Morel logic is certainly great when you run complexer conditions.
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter
My name is Christiaan and I support SMB with calculations (budgets and — Human Resource — planning) and I prefer using Coda to get the job done.
Coda comes with a set of building blocksーlike pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your docーso anyone can make a doc as powerful as an app (source).
Not to forget: the Coda Community provides great insights for free once you add a sample doc.
If you enjoyed this read and would like to get more Coda related content, please consider a Medium membership. It is it only $5 a month, and you’ll have access to every article ever published on Medium. If you sign up using my referral link, I’ll earn a small commission.