Dynamics CRM/365 – Technical things you need to know as a functional consultant

By Ritchey Hazeu (Dynamics 365 Consultant @ Capgemini)

This time: Tools!

When you’re surrounded by developers, you hear a lot of tools which they use to manage their code. They are talking about Visual Studio, Plugin registration tool, SDK, Azure DevOps Server (before TFS), etc. In this blog we will tell you more about those tools and how they are being used.


Visual Studio

VS is being used by developers to develop new functionality. VS supports 36 different program languages, has a built-in debugger (a tool to write good code) and a code profiler (measures the functions which are created by the developers).


Azure DevOps Server (before TFS)

When you’re working in a team with multiple developers and they are all creating code in Visual Studio you need a place to store this code. You also need to make sure there is a version control. When developer A is working on a piece of code, developer B needs to be aware of this. Azure DevOps Server (before TFS) is providing this so called ‘source code management’. The most powerful thing Azure DevOps Server (before TFS) provides is that it covers the application lifecycle. When you want the store the code in the cloud the name is Azure DevOps (before it was called VSTS), and the code is stored in Azure.


SDK (Software Development Kit)

When developers first start working with Dynamics CRM they will download the SDK because it contains the following:

‘The SDK includes an architectural overview of Dynamics 365, the entity model, security model, and web services. Sample code and walkthroughs are provided to guide you through the new features. It also contains information for developers who customize the web client or Dynamics 365 for Microsoft Office Outlook, including scripting, integration of custom webpages, and sample code’ (quoted from https://www.microsoft.com/en-us/download/details.aspx?id=50032)

If will give the developers a bunch of insights in the code which they can use to start off with their own developments.


Plugin Registration Tool

Before we will explain this tool, we need to know what plugins are. A plug-in is a custom made (C# or .net) function that is used to extend the standard functionality Dynamics CRM offers. They can run synchronous & asynchronous, when you execute something synchronously, you wait for it to finish before moving on to another task. When you execute something asynchronously, you can move on to another task before it finishes. Plugin act on a certain event in CRM.

An example: You want to automatically send out an e-mail to your customer when the SLA of the case is breached.

The plugin is being created in Visual Studio, with the use of the SDK (you need to include references to Microsoft.Xrm.Sdk) and stored in Azure DevOps Server (before TFS). The plugin is registered in the Plugin registration tool, with the tool you can connect your plugin to different instances in CRM.


Custom Workflow

Plugins can be executed on a wide range of events on a CRM entity. Custom workflows are bound to the events which you can see in the CRM application (Create, Update, Status Change, Delete and On assign). Workflows are instead giving (non-technical) users more insight in the process because it’s visible in CRM, unlike the plugin process.

Another difference between workflows and plugin is that workflows are running async and plugins are running sync (read a little bit back for the explanation).

When you create a Custom workflow you also create an assembly and register this just like a Plugin.



Next article will be about the Architecture of a CRM (on-premise) environment!