In our solution, there are many "read only" fields that are populated by trigger/scripts. These are to copy data that cannot be referenced in an FVA, or building summary tables that cannot be done with a QBR, or calculating internal metrics, or calculating sub-states of the State field, etc. The amount of data, and size of the text fields, that is injected into the history of an item is enormous and renders the History tab essentially unusable to our users.
Our request is that this is implemented in a way that does not block the existing use, or change the default behavior of the existing fields. By having a property on a field that is "Disable History" that is false/unspecified by default, this change would not affect any of the current customers. Disabling the history of a field has to be performed specifically.
If this field is toggle (turned on, then turned off, and then turned on again), we do not care what happens to the history. In other words, when disabling the history, there is no need to update the existing history one way or another. This capability is simply a mechanism to stop, or start, the history. If a constraint is required that requires the history to remain disabled forever, once disable, that is acceptable.
This is in the list of top 5 complaints/requests from the user-community of our organization.
