If a function can't be performed by an automation, you should get that feedback when designing, not only when it fails later

Broadly speaking Automations seem pretty weak relative to button actions in Coda. It’s a bit annoying they have different rules but that can be worked around. But its straight-up bad design when they appear in set-up like they can do things that they actually can’t.

I am allowed to write an automation with the formula that includes a pack table sync. When I press “test rule”, it even appears to work! But then it fails only when its actually in-use and I find out an an error that “Trigger sync can’t be used in automations” from the error log.

Why does it work when I test it, but not when it’s scheduled?

  1. Best case, I should be warned in the formula that I can’t use this function when writing the formula - just as it would warn about non-existent functions or bad syntax. But failing that…
  2. It should in the very least fail when I press “test rule”!

I assume that the test rule is using my privileges as a user to test, but this makes no sense. Shouldn’t it always be testing as if it was the “Automation Bot” trying to do it?

Is this the only limitation or are there others? Am I missing something here?

7 Likes

+1 Automations are quite powerful and one the most important features in Coda but are badly designed

In most cases I use canvas buttons with filters which are just triggered by automation. For example if I want to notify a person X number of hours before a task deadline I create a canvas button which checks for each row/task if it is X hours before deadline and notifies the person. Automation triggers the button every hour. Sometimes minutes are important but that’s too much for Coda.

2 Likes