Understanding usage of transient fields in Microsoft Dynamics CRM

By - April 10, 2015

A transient field is one for which the contents of the field are typically valid only at the point the data is calculated or obtained. For example, while a person’s birthdate does not change, their age could be different each time the record is viewed. These fields may provide valuable information to the end user, but one must take care to ensure that the value is updated or calculated at each point the information may be consumed.

In general, I try to avoid adding fields to a Microsoft Dynamics CRM entity when there is no value in having the data stored in the database, but there are a number of situations where I have found transient fields to be quite useful:

  • Calculated fields (such as age) that can be set via business rule or script
  • Display of data obtained from entities not directly associated to the current record – in situations where an embedded QuickView is not possible, a set of transient fields can be populated via script or plugins that fire on Retrieve of the primary entity
  • Inclusion of data from non-CRM sources when an approach such as an iFrame or web resource does not satisfy needs in terms of display or access to the data via script on the form – again, a plugin firing on Retrieve can retrieve data from an external data source and present it to appear as part of the core entity
  • As a triggering mechanism or to provide additional information to a plugin or workflow.  One example where this approach was used successfully involved support for a selection of a group of related items. In this case, a user could select a service needed to resolve an incident. Depending upon the selected service, Dynamics CRM needed to present the user with a set of related services are often needed in conjunction with the primary service. Use of a hidden transient field allowed the list of services to be provided to a plugin; a script was employed to set the field value based on checkboxes selected in an iFrame of potential services.

There are some guidelines I usually follow when a field is intended to be transient in nature:

  • Indicate that the field is transient in the attribute name, e.g. new_xyzvalue_transient
  • If the field is not being used to drive a server-side process, it should be set to never submit on the form
  • In most cases, these fields should be disabled if visible
  • If the field is being used as a plugin or workflow trigger, the value should be cleared when possible – within the server process itself if practical, or on load of the form.
  • Above all else, these fields should never be included in reports

As with all technical approaches, keep in mind that just because something can be done does not mean that it should be done. A thorough understanding of the business need for the information or process is ultimately what should drive the solution approach.  If you are looking to extend your Microsoft Dynamics CRM solution, we have resources from the basic “out of the box” model to a complex architecture featuring custom development. Contact our professionals today to learn more – crm@rsmus.com or 855.437.7202.

By: Tim Resch – Great Lakes Microsoft Dynamics CRM partner

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *