Hi!
I would like to know if there are any best practices when working with Calculation fields, especially when the calculation is more complex and refers to multiple fields both in the current app and in related items.
Are ‘Helper fields’ of any value? meaning if i need to retrieve data from multiple fields in a related app, is it better to create a field with the JSON value of all the related fields instead of calling all the fields again in each app? is there an advantage to using automations to update ‘Helper fields’ instead of using calculations?
What are the most beneficial things to change in the code when copying over calculation fields from Podio in order to optimize speed?
I would be happy to hear any other tips or suggestions people have found when working with calculation fields.
thanks for reaching out and starting this disccussion. I will provide some insights and advise from our internal engineering perspective, which should mostly align with user interest: Solving problems in an efficient and maintainable way, while having a great user experience and performant results.
Some general advise regarding your conrete questions:
Reaching to multiple fields in another app is not a problem and should not cause performance issues. Our engineering team has considered the amount of data here, and also records with many relations should not cause issues
Heavy computations inside calculation fields could lead to delays: Example: Building large arrays and iterating over them. This is only relevant for very large datasets (1000+ array entries) or nested loops.
Automations have a siginficant performance overhead compared to calculation fields due to their power and added capabilities. Consecutively, calc fields are always the preferred way in terms of resources and performance for users, if you do not need the automation functionality such as asynchronous operations, writing data to Tape etc. Of course, automations allow better debugging with logs, and run history. In short: be sure to calculation fields if applicable, use automations otherwise.
Migrating from ES5 / Podioas a summary of the feedback of several Tape partners:
ES5, which is used by Podio, stands for ECMAScript 5 from year 2009. Tape uses ES2021 from the year 2021, which is roughly 12 years ahead. Moden JS may be faster in execution, but the main advantage in Tape is not performance, but rather readability and maintainability. Simply write easier, more consise code while still supporting the old syntax. For obvious reasons I would always recommend leveraging the new syntax, but our users are free to choose and also continue using the old syntax they may be used to. Our examples and advise will usually leverage modern syntax.
Another reason to use JavaScript is that compatibility is king inside the JS ecosystem. This is also a reason why we were able to upgrade our Node.js (which is our secure JavaScript execution environment) from version 14 to 16 and then to 18 recently - without anybody noticing. This made Tape more secure, reliable and performant. While other languages such as PHP break existing syntax, we can guarantee that old scripts will always work in calculation fields and workflow automations which spares our user base a potential headache in the future.
Things that may impact your organization’s performance (luckily only your org, here’s how)
Changing a calculation field script in an app with many records. This is obvious, as the field value(s) need to be recalculated for all records. This can cause heavy load, and may lead to some waiting time inside of your organization. When developing a script, testing etc. be sure to either test that inside a smaller app or use a playground such as: Node.js Playground - StackBlitz
Large imports to an existing app with calculation fields, for the same reasons as above
I hope this first chunk of information and context is helpful to you and others. Feel free to ask any questions or related concerns, so we are able to respond here.
Hi @Tim - reading a value from a selected record of another App (think about parameter) works fine in automations with the search operation. But in field calculations, that would not be possible, right? This would be some kind of “select” statement with some parameters…
(Example: I would like to sum up a value from related records in a calculation only records within the last 12 month).
Some general advise regarding your conrete questions:
Migrating from ES5 / Podio as a summary of the feedback of several Tape partners:
Things that may impact your organization’s performance (luckily only your org,