The topic of field updates is broad and touches on considerable functionality in both platforms. My definition of a field update is an automatic modification of one field triggered by a user action. This action might be a button click, change to a field value or the addition of a new dependent record.
Automatic field updates are critical to any workflow within CRM and it is not surprising that Dynamics and Salesforce provide a variety of methods to accomplish this task. For the most part I try to stay with out-of-the-box options that an experienced administrator can employ. My reason for narrowing the scope is that from a development perspective almost anything can be accomplished and I would rather focus on how each platform automates these processes without considerable coding.
What is Real Time?
Some field updates occur behind the scenes while others are designed to be immediately apparent to the user. In terms of administrator-instituted capabilities, a major difference between the platforms relates to when a change is propagated. Both update fields during the save operation. Once the page refreshes post-save both platforms display the updates. A case can be made that this alone is not always adequate to achieve the optimum user experience.
Suppose the Product Id field on an opportunity is a concatenation of the product name and the product model number. If either of these were changed an instantaneous update of the Product Id field adds to the user experience. Granted, this is not a very compelling example, but a request like this is not uncommon.
Enter JavaScript
Yes, I am already breaking my rule about no-code solutions. Dynamics provides a rich set of fairly simple JavaScript properties that can provide this functionality without altering the form at all. So, although this is technically “code” I imagine that an administrator can follow cookbook directions and achieve the desired results.
This entire process takes about 10 minutes to set up. A single JavaScript resource is associated with a form, in this case opportunity. It is good practice to have one JavaScript web resource per form named accordingly. Wrapping it in a global class also helps differentiate your code from that of managed packages. A field on-change event is then associated with the appropriate method and the Product Id in the example above is filled in as soon as the user tabs out of the source fields.
The major difference I alluded to earlier is that Salesforce does not provide this real-time feedback at all. While this distinction will likely not come up in the sales process and therefore is not a deal-breaker it is significant. Users and developers familiar with Dynamics will likely find this limitation an unwelcome paradigm shift.
Focusing on Visibility
Probably more common is the desire of our clients to toggle visibility based upon field values. While this is slightly outside of the field update topic I believe it is closely related. Making a field invisible (and potentially clearing it) is often a consequence of a field update. For example, you may want to clear and hide the phone number if the “Do Not Call” box is checked on a contact’s record.
As we have seen before both platforms are adding new features that provide administrators more power without resorting to code. Prior to Dynamics 2013 JavaScript similar to the above was used toggle field visibility. Since the release of Dynamics 2013 business rules provide a no-code option.
Dynamics Business Rules
In my opinion this is a nice feature although limited. Both platforms have a history of introducing features that meet the needs of a few common scenarios without dealing with the broader picture. The current capabilities of business rules are:
- Set field values
- Clear field values
- Set field requirement levels
- Show or hide fields
- Enable or disable fields
- Validate data and show error messages
Note that the rules only apply to fields and the permutations are limited. These rules cannot replace the JavaScript we used in the previous example. Below is an example of using a rule to hide the Product Id field based upon the purchase time frame.
As these platforms evolve and retain backwards compatibility the redundancies multiply. This business rule can also be implemented as JavaScript and as we delve further into techniques for field updates we will see more of this.
Again, Salesforce at this time is not able to handle conditional field visibility without custom pages. Check out this post to track the latest developments. Judging by the number of votes this is a hot topic and Salesforce is taking it seriously.
Formula Fields
Where Salesforce lacks in real-time updates it excels in post-save field updates. In another post we will investigate workflows. In both platforms workflows are powerful tools. The downside is that they take time to configure and maintain. Salesforce, unlike Dynamics, relies more heavily on field types to carry out tasks that Dynamics business rules have only begun to address.
Let’s revisit the Product Id concatenation example above using Salesforce formulas.
The Project Id field in Dynamics is a text field. This field is updated through JavaScript and the field actually contains the concatenated text. The Project Id field in Salesforce is not a text field and holds no data itself. It is of type “Formula” and is a calculated field. The formula looks very similar to the one we created in JavaScript. There are no separate web resources to load and no events to hook up. The formula and the field are one. Furthermore, the interface includes wizard buttons that make it very easy for even a new administrator to implement this functionality.
In a production formula I would utilize more of the functions available in formulas to check for empty fields and always present a correctly formatted Product Id.
Calculated Fields in Dynamics 2015
Considering most instances of Dynamics are pre-2015, the JavaScript solution is the simplest way to deal with this use case for most implementations. For those using the latest version, the 2015 release adds an option similar to what Salesforce provides with formulas through calculated fields.
Note that the calculated field editor is very similar to the one we just used for the visibility business rule. Compared to Salesforce formulas the operators and functions are fairly limited. I suspect that the range options will be expanded in subsequent releases. Also, like Salesforce, this is updated on save, not in real-time.
Editing Philosophy
I want to tie a few loose ends together before ending this post. One of the reasons for the difference in the real-time responsiveness is related to how editing is implemented. Dynamics offers in-line editing whereas Salesforce displays an edit dialog overlay which displays only those fields that can be edited.
A common complaint is screen clutter. Salesforce addresses this nicely with the field display restrictions in the edit dialog. The bottom line is that you cannot have it both ways: either fields can update real-time when editing the entire form or the editing is restricted to only those fields which can be edited making these real-time updates impossible.
Arguments can be made for both approaches and I think that each system has done a good job at implementing them. The biggest take away for the administrator moving between platforms is sensitivity to the users. This is a paradigm shift and a well-executed training program is a must.