Plug-Ins, Workflows, and JScripts: What are these “developeresque” sounding things?

Written By: Josh Behl

from April 12, 2013

For those of your who are experienced in the ways of Microsoft Dynamics CRM, the terms “Plug-In”, “Workflow”, and “JScript” are commonplace and may beg the question, “Why spend time writing an article such as this?” I recently was having a conversation with someone who had a number of years of background using the product as an end user but confided in me that they had never really understood the difference between these terms. So, I figured I would answer the question for others who also may find the mean of these words to be elusive.

Workflow: A workflow is merely an automation of a business process. It is a business process of some kind that occurs when a specific action is taken on a type of record. For example, every time someone is assigned a lead, they receive an email telling them that they have been assigned a lead as well as some details about the lead. Think of it as a process where an event of some kind occurs, the application recognizes that event, and then takes action on that event. Now, this is a simple example; however, these automations can certainly range from the simple to the moderately complex. Within Microsoft Dynamics CRM, there is a tool which allows people to create these automations. Within the product, the workflow functionality is part of an all-encompassing suite of automation tools referred to as “Processes”. We can also create something called a “Dialog”. A dialog is like a workflow in that they are designed to automate some kind of business process. However, where a workflow will run behind the scenes, a dialog will prompt the user to answer questions about the process as the automation takes place. Think of it as a “wizard” much like you use when you install a piece of software. You answer the questions, you click next, click next and so on, and then in the end you have software installed on your computer. A dialog is the same conceptual thing. The nice thing about workflows and dialogs is that they don’t require a developer background and can be created, updated, and used directly within the interface.

Plug-In: A plug-in, like a workflow, is also an automation of some kind of business process or logic. The biggest difference is that it is 100% code. If you are not a developer, you will not be writing a plug-in anytime soon. A plug-in is a .NET assembly (which is like a big chuck of code packaged together) that is essentially injected into the Microsoft Dynamics CRM platform. When it is injected into the platform, the developer will indicate what entity it will be triggered upon and what event will trigger it. The nice thing about plug-ins is that they essentially provide almost total flexibility in regards to automating processes or incorporating business logic into the application. A workflow has limitations in regards to what events and even entities it can leverage. A plug-in, on the other hand and for the most part, provides total flexibility in that sense. Anything I can do with a workflow, I can do with a plug-in but most things I can do in a plug-in cannot be done in a workflow. However, I have a slick interface to create a workflow and for plug-ins I do not.

JScript: A JScript has a couple of synonyms that may help put it into a better context: “Java Script” and “Client Side Script”. JScript is essentially Java Script… it is just the Microsoft implementation of Java Script (there are differences of course, but for the most part they could be considered the same thing if you are not a developer). These are snippets of code that can be added to a number of events in the application such as the changing of a field on the form (this is called the ‘OnChange’ event), the saving of a record from the form (this is referred to…can you guess…the onSave event), and when the form loads on the screen (this is the OnLoad event). While you will likely need to be a developer to be doing this, it is much easier for the non-developer Microsoft Dynamics CRM administrator to include this kind of code into the application because you can simply find code examples from many resources, open the app, put them in the correct places, test it, publish it, and you are off to the races. (I am simplifying this obviously) One key thing to take away from this description is the fact that these scripts are placed on the form and will trigger as the user is interacting with the record. Unlike plug-ins, these scripts will only run when the user has the form open and is doing stuff. A plug-in will trigger and run your logic regardless of how the event is triggered (e.g.: data migrations, other workflows, direct user input and updating of records, and so on). Also, for the JScripts to run, the fields they interact with must be on the form. This script is looking directly at what the user has on the screen. If the “thing” the code is looking for is not on the screen/ on the form, the code cannot see it and as such cannot perform that business logic.

I realize that for developers, I have potentially over simplified much of this (that was purposeful). It is often easy to forget that our customers don’t speak the same “CRM Lingo” language that we often use amongst our peers. My efforts are to help level the linguistic playing field just a little. For more information about all of these concepts, check out the online Microsoft Dynamics CRM SDK You can also check back to the Dynamics University blog as well for other articles pertaining to plug-ins, JScripts, workflows, and many other topics.