Dynamics CRM: JScript vs workflow – Caveats
JScripts in Dynamics CRM are a powerful feature to enhance the user interface in Dynamics CRM. We can use JScripts to perform calculations and validate fields in forms in order to introduce a better user experience. However, JScripts are a client-side based, and only work with the desktop-based (main) forms. In other words, if the user is accessing Dynamics CRM through a mobile device displaying the mobile forms, or using a 3rd party client for a tablet device, the JScripts will not be loaded at all. Workflows on the other hand are server-based, and they will execute no matter which device and client is used to access Dynamics CRM.
This often raises the question of JScript versus workflows when customising Dynamics CRM, particularly when designing a sales pipeline workflow. In this posts I explain how to combine the usage of both JScript and workflows in order to get the best of both worlds, and the most out of Dynamics CRM.
Overview
Dynamics CRM 2011 is a web-based application that uses a multi-tier architecture. This means that the Dynamics CRM platform serves as an intermediary between the client access users and the data. The application business logic sits in this intermediary bit, and this is where Dynamics CRM workflows are located. When a workflow is executed, it is executed at the server level, not at the client level (e.g.: Internet Explorer or Microsoft Outlook). JScripts on the other hand are interpreted at the client level.
Considerations
Consider my previous Sales Pipeline tutorial (see second post of the series). For the Opportunity record we added an option set (i.e.: a drop-down menu) where the user can select the stage of the sales pipeline for the opportunity is. The current sales pipeline stage, along with the user rating (e.g.: Hot, Warm, Cold) calculates the Probability for the opportunity record. We achieved this with the use of JScripts, which are quite handy since JScript provide users with an on-the-fly update. As the Pipeline Phase and Rating fields change, the Probability field is immediately recalculated.
However, since JScripts only work on main forms, this whole logic would be simply disregarded if the record is being edited through another method, such as through a mobile form , a web service call or a 3rd party client for tablet devices. How can we solve this issue?
About Mobile Express: Mobile Express is how Microsoft calls the mobile-friendly forms that can be used to access Dynamics CRM with mobile devices. Microsoft cleverly calls them “express” so they can argue that they are far from being a full-featured solution. So we must work around the limitations of these forms. Even though Microsoft calls them “express”, at the moment these mobile forms lack some fundamental functionality (such as disallowing users to edit records) so I am very reluctant to use them. I suggest you also avoid using them if you can.
Hacking Mobile Express: It is possible to modify the Mobile Express Cascading Style Sheet (CSS) files to hide the New, Edit and Delete buttons that would allow users to create or modify records bypassing any JScript you have. You can find the instructions on how to do it by at this forum post. Please bear in mind that this hack is NOT supported by Microsoft. Thanks to Nuno R Costa for the tip.
Consider now the workflows introduced in my Sales Pipeline tutorial (see third post of the series). If you look into the Sales Process workflow, you will notice that at every stage (1 - Prospect, 2 - Proposal, 3 - Negotiation) we wait for the Process Code (salesstagecode) field to change (which moves the workflow to its next stage). However the workflow doesn’t perform any actions.
Solution
The solution is to add an action at every stage to replicate the functionality of the JScript. Since workflows work at the server level, no matter what client or method was used to modify a record the workflow will be triggered as per its rules and its actions will take place. One might wonder if that is the case, then why bother with JScript at all. But remember when I said in the introduction of this post. JScript is all about enhancing the user experience, while a workflow works in the background, away from the user’s eyes. The issue, particularly for Dynamics CRM on-demand users, is to design a workflow using the built-in workflow designer and avoiding Visual Studio.
So let’s get back to the Sales Pipeline example. Consider the following screenshot of the Sales Pipeline workflow:
Notice that under each stage, between the lines Wait Until Opportunity:Process Code equals [...] and Otherwise, wait until Opportunity:Status equals [...] there is a line that says Select this row and click add step. This is because there are no actions being executed there. What we want to do is select this line at each stage, and add the appropriate actions to replicate the functionality of the JScript.
For example under the first stage (1 - Prospect) we would add an action to change the value of the Sales Pipeline field to 2 - Proposal. Moreover, we would need to add an additional wait condition to update the Probability field according to the option selected in the Rating option set. For more information on workflow conditional waiting, please refer to the third post of my sales pipeline tutorial.
Final Words
At first sight, if we could design a Dynamics CRM deployment that relies completely on workflows and no JScripts at all, it might seem as we could have a fail-proof business process. However the server-side nature of workflows at the platform layer makes them more linear and less receptive for situations in which users require a more dynamic response, such as on-the-fly calculations and conditional formatting of fields. When dealing with JScripts and workflows don’t start from the premise that you must choose either one of them, but how you can combine both of them. Finally, bear that JScripts only apply to browser-based forms (i.e.: Main Forms). In other words, all of your JScripts will be disregarded if a user manipulates data through Mobile Express forms, or through some sort of integration with another product.