One of my previous articles, I have explained about how cool the Calculated Fields are. But, as always there is a catch, i.e. there are several limitations. So when you decide to use calculated fields, you need to remember these.
- You cannot modify or update the values of a calculated field at a later time via Workflows or Plugin.
- Existing fields cannot be converted to a calculated field. Only option is to create a new one and designate it as a calculated field.
- Duplicate detection rules do not apply for calculated fields.
- Sorting is disabled on calculated fields when there is a fields of a parent entity is involved and when another calculated fields involved
- In any case, calculated fields cannot be spanned more than two entities. For instance, a calculated field cannot contain another calculated field from another entity that uses a fields from a third entity.
The real world scenario:
One of the support contract that I got from the client, who had the solution implemented from another consultant, was using calculated fields. Since their requirements were growing, and I had to implement few plugins and workflows for these calculated fields. With plugins and workflows, calculated fields were useless. It involved me to do the following to give them a proper solution.
- Create non calculated fields similar to older calculated fields.
- Update data to new fields.
- Hide the older calculated fields from forms.
- Use the new fields with the plugins and workflows designed.
The take away from this is that, you have to be very careful about when utilizing these features. Rule of thumb, you need to think through to the future. In the above scenario, if the previous consultant has given enough thinking, this additional work would have been easily avoided.