Let’s say you have a field that requires complex calculations that are impossible to express as a calculated field. For example, the requirement could be to figure out the “real” full name for a contact taking into account the country, ethnicity, contact’s preferences, their royal title, and a phase of the moon.

The first reaction is to write a real-time workflow or, failing to express complexity declaratively, a plugin. So far so good, except one tiny detail. Every time you do that, you’d need an update to the customer record, changing modified on. Some customers, unfortunately, rely on modified on value to perform reporting magic. And that would be fine as long as the input values have indeed changed, e.g. contact acquired a new title or got married. But let’s say, the algorithm has been improved and you need to perform bulk recalculation of the full names. In this case timestamps will change and customer will get understandably angry.

The solution is to “hang off” a separate entity on the side, pretend that it is one-to-one with the contact entity and update a field on that sibling entity with the magically calculated value. Since there is a relationship in place, it’s easy to include this value in the views, reports and, using quick view forms, on the contact form as well. Timestamps will change but only on these calculated entries and not on the contact entity.

Illusion of integrity achieved.