Free book idea for aspiring CRM authors out there: “1001 uses for calculated fields.” (We’ve already written a few, you can take this one).
I’m continually amazed by the novel uses for calculated fields that go beyond the obvious uses. Latest example–working around crazy field limitations.
Consider the following example: We have an opportunity configuration where the estimated revenue is the total of the opportunity product plus the value of a couple of fields from the opportunity record. We have a plugin that handles the calculation, so we do not want the estimated revenue field to be “system calculated.” All good, except there is no way to make the estimated revenue field in CRM read only when the opportunity is set to “user provided.” Even if you set the field properties to “read only,” or you create a business rule to lock the field, the system form scripts will set the estimated revenue field to editable when the opportunity revenue is set to user provided.
Enter calculated fields.
I created a calculated field and called it Estimated Revenue Display. I set the calculation action to the value of the estimated revenue field.
Then, I put the calculated field on the opportunity form right next to the Estimated Revenue field. I edited the form field properties and changed the label to “Estimated Revenue.”
Then I set the properties of the Estimated Revenue field to not be visible.
The result is a read-only user provided Estimated Revenue field.
Good Example on using calculated fields to work around field restrictions.
You can use the calculated fields form for creating forms with dynamically calculated fields and display the result.