In the last post we explored updating fields based on changes in the same entity’s form. Dynamics utilizes simple JavaScript that changes the value of a field. Salesforce achieves a similar effect through the use of a formula or calculated field. The end result was a field that concatenated data from two other fields.
Cross-Object Field Updates
This post introduces cross-object field updates and the workflow. Both platforms can perform complex operations through workflows. Future posts will give an in-depth comparison of workflows in Salesforce and Dynamics. Here we are going to limit ourselves to a simple use case that involves two entities: opportunities and accounts.
Scenario: the account form has a text field entitled “Current Opportunity.” The value of this field is the name of the most recent opportunity associated with this account that has estimated revenue greater than or equal to $75,000 and has a probability of closing that is 70% or greater.
Requirement: the Current Opportunity field is updated each time an opportunity meeting the criteria is created or updated.
So, let’s be realistic: this example is not. I kept this intentionally simple to demonstrate the field update aspect of workflows. You should quickly figure out that there are a lot of holes in my logic, and hopefully this post will serve as an exercise in spotting a bad process.
Selecting Conditions
When creating a workflow there are two key decisions in both platforms. The first is when the update occurs and the second is what conditions must be present to trigger the update. Salesforce and Dynamics differ considerably when it comes to the first step.
Dynamics offers five scenarios compared to three for Salesforce and should be fairly self-evident. In both cases the rule will fire when a record is created. From that standpoint there is little difference. The update conditions are more interesting. Note that Dynamics keys off of changes to specific fields whereas Salesforce fires the workflow after any change is made to a record. Of course, the process will not complete unless further criteria are satisfied on both platforms.
Although it is not visible in the above figure I set the Dynamics workflow to trip when either the probability or the estimate revenue fields are altered. Before reading any further consider the impact of the evaluation differences. Given the criteria I have used for this example, Dynamics is going to yield behavior closer to what is desired. Have you figured it out yet?
Consider a scenario where opportunity A is created and it satisfies the criteria. The account should now show this opportunity. Opportunity B is created several days later and it also meets the criteria. Of course, the current opportunity on the account is changed to the second opportunity’s name. This is where it gets interesting. Let’s see what happens when Opportunity A is edited in both platforms and an unrelated field is changed.
Dynamics: since neither the probability nor the estimated revenue fields have changed the workflow will not be triggered. The account record will still show Opportunity B as the current opportunity.
Salesforce: the rule is triggered every time the record is edited and the criteria are met. Since Opportunity A still meets the criteria the account record will now show Opportunity A as the current opportunity even though Opportunity B is newer. Most likely this is not the desired behavior.
Restricting Updates
How can we fix this issue? Recall that there are two steps: triggering the workflow itself and fulfilling the rule criteria. With Salesforce the workflow rule will fire regardless of what field is updated. This means we have to adjust the rule criteria.
Previously we created criteria to satisfy the rule. This is too limiting for our use case and it requires running the rule against a formula. The ISCHANGED() function is used to detect if a field value has changed during the edit. Of course, the probability and expected revenue criteria are also included. Also note that the evaluation option is changed from “meets criteria” to “every time it’s edited.” If this is not done the formula will not validate.
This now will function exactly as Dynamics does in our earlier example. However, there is still room for improvement. Recall the scenario where Opportunity A was replaced by Opportunity B as the current opportunity. If the expected revenue for Opportunity A was $80,000 and now is $83,000 the workflow rule will still fire replacing Opportunity B.
With Salesforce we can use another function called PRIORVALUE() which gives us the value before the record is edited. If the initial value of the expected revenue is already over the threshold then changing the revenue should not trigger an update. This simple addition tightens up our logic and provides a better user experience.
This level of evaluation is not possible in Dynamics without the use of code, although it definitely can be done. This requires a custom step as described in this post.
Lessons Learned
Updating a field through a workflow only scratches the surface of what workflows can accomplish. Although the general concept of a workflow is the same, the functionality differs significantly between Salesforce and Dynamics. Subsequent posts will explore these differences.
For now, the one piece of advice I give to anyone new to workflows and automation in general is to walk through all of the scenarios before you touch the keyboard. Workflows are complex and they are not easy to troubleshoot. Even when they do seem to work it is not uncommon for the customer to be dissatisfied with the results because the consultant did not put enough effort into the design.