I love the Calculation field, however, when I need to put them into production to do something meaningful, I am forced to back away from using them and reverting to an event triggers and webhooks to do my calculations which I would rather not leave in the hands of these types of back ends. Some roadblocks include not being able to use a list box to drive a calculation, calculations using deep field linking, and typecasting strings as numbers. Here are a few examples.
We have a Level field on our user table to determine if the user is Junior, Mid or Senior level. We use this field for lots of things, however, we are not able to use this to help with budget hours or dollar estimations without a lot of effort ( creating side car percentage field that are updated by a webhook)
We have a number of tables that help us track and manage our resource plans ( Resource Plan, Booking, Human User, Department, Role). Regretfully if we want to use a calculation field on any one of these tables of data we are forced to build a webhook to trigger the maintenance of this data being mirrored on the table where the calculation is needed.
Wondering if other users are hitting these types of roadblocks and might speak up here.
Since its release, the calculate fields has been useful for some basic calculation cases in the grid. We have re-visited this module and add date/date fields in the calculated fields option.
But yes, it’s not as strong and robust as it should be. I think calculating with Level List Field is a good use case we could think of. You could follow the post below to submit your use case as feature request. Remember to describe all your use case as detailed as you can.
Hi, just want to chime in about the Artist skill level part. While @Romey’s case sounds like a feature request, we do promote the following for setting up skill levels on Tasks:
I wanted to add this in case this sparks an interest in setting up something with skill levels.
