Enterprise resource planning (ERP) and customer relation management (CRM) systems are very helpful in organizing, streamlining, and structuring business processes across the company. They allow companies to automate certain management and business tasks and unify data across the board, helping them to reduce overhead and make the overall workflow more efficient. To fit the needs of a large number of companies across different industries, such systems come with a wide variety of features spread between several modules optimized for different departments.
Yet, despite the rich feature set, many companies face the need to tweak said system to their own unique needs. To meet this demand, many products come with necessary tools that allow their clients to implement custom solutions within the system.
In this brief overview, we will cover a SaaS based CRM solution from Microsoft called Dynamics 365, and take a look at what tools it provides for extending functionality and importing data. As with many CRM systems, development and support of custom modules often requires a team of experienced engineers and QA specialists, but for many companies such an investment allows to immediately extract more value from the system and proves cost-effective in the long run.
Dynamics 365 is a ERP and CRM system, launched by Microsoft in 2016. The system is positioned as an extended relationship management (xRM) solution, as it can be configured to manage any given process and reflect relationships in any business domain.
In the biggest Dynamics 365 package, the following modules are pre-installed:
- Field Service
- Project Service
- Resource Scheduling
Various packages are available, containing different collections of modules. You can subscribe to one or several packages.
You can get access to Dynamics 365 by
- Buying a license;
- Being a Microsoft consultant;
- Subscribing to the Microsoft Developer Network Academic Alliance (MSDNAA);
- Using an online trial version for 30 days or downloading an on-site trial for 90 days.
For the Microsoft Dynamics 365 deployment, there are three options available:
- Get a version that’s already deployed on Microsoft’s servers (crmX.dynamics.com, where X is the server number).
- Deploy an on-site version and manage it yourself.
- Use the services of a third-party supplier that deploys a system on their side and grants you access to it.
More information on the constraints of each option can be found at:
Dynamics 365 has a web interface that can be accessed at companyName.crmX.dynamics.com. This interface can be used to perform all management activities.
A set of dashboards can be found inside each solution for a particular business domain. These dashboards provide graphic representations of data and show connections.
The main purpose of Dynamics 365 is to make data entities and the connections among them available to every business domain. The web interface provides a wide range of functions and customizations. It’s possible to adapt existing data entities or create new ones in order to describe business processes.
It’s possible to implement necessary Dynamics 365 functionality yourself. A special software development kit (SDK) is available for such purposes.
In previous versions of Dynamics (Dynamics AX), it was necessary to write code in the X++ language (an object-oriented language with similarities to C#) in the MorphX integrated development environment. This X++ code was then compiled into some sort of intermediate language. However, Microsoft developers recently updated Dynamics so that now the code is compiled to a full intermediate language. Due to this update, it’s possible to write code in any language supported by the .NET platform.
The SDK includes various Microsoft Visual Studio projects. Everything that’s required for working with the CRM is pulled through NuGet. You can find more detailed information in the examples.
9 Tools for Design-Time Code Generation
You can implement the following additional functionality in Dynamics 365:
- Clients in the form of console utilities or WPF (Windows Presentation Foundation) for PC or mobile (in Fig. 1, the green rectangle under .NET client).
- Extensions for processing of the Dynamics server itself (in Fig. 1, the green rectangle under .NET plug-ins and workflows on the left).
- Extensions for processing Dynamics web forms (in Fig. 1, the web application section on the right).
Data can be imported via the web interface. The following file types are supported: *.xlsx, *.csv, *.xml, and *.txt. The interface can analyze what types of data are included in a file based on headers. Moreover, depending on the model that data is being uploaded to, configuration of field mapping will be offered. Import settings can be uploaded and saved so you don’t need to manually specify them each time.
There’s another more complex way to import data through code (which corresponds to the first case mentioned in the previous section). A program written in C# can read data out of any file. Rules for correlation between data and the model on the server (or the model itself) can be created right in code. Then all this information can be sent to the server. This method can be used either when it’s extremely difficult to convert data to a *.csv file or when complex modifications or filtering, which cannot be configured through the web interface, has to be applied to the existing *.csv file.
Now, let’s look into brief Microsoft Dynamics 365 tutorial regarding server plug-ins. There are two types of plug-ins (extensions): synchronous and asynchronous. Synchronous extensions are added as part of Dynamics’ processing queue. Asynchronous extensions are processed in a separate pool after a certain operation has been executed.
Synchronous plug-ins can be assigned to events occurring either before an operation (in Fig. 2, the pre-event option) or after an operation (in Fig. 2, the post-event option).
The pre-event stage includes pre-validation – when it has not yet been determined whether a user can execute the operation – and pre-operation, after execution has been allowed.
It’s important to keep in mind that pre-validation can be performed out of transaction, while pre-operation cannot. This means that if an exception is returned from the pre-operation plug-in, the transaction will be declined. At the same time, for the pre-validation plug-in it may be accepted. Therefore, pre-validation can be registered as part of a transaction.
You should take into account that Dynamics 365 doesn’t allow selecting types of events for plug-in connections. Based on analysis of data transferred during an operation, it must be decided whether a plug-in should perform any actions. Therefore, it’s important to understand the necessity of a plug-in application and to return control to the Dynamics 365 processing queue as soon as possible. In this way, the processing speed will not be slowed.
Building SaaS CRM systems: brief overview
Dynamics 365 doesn’t allow you to perform any custom actions during operation processing (in Fig. 2, the >platform core option). Also, it’s important to note that all plug-ins are launched in a sandbox so they don’t have direct access to the file system, web resources, or several other functions.
Asynchronous plug-ins are processed in a separate queue after a certain operation has executed (including all synchronous post plug-ins).
It’s important to keep in mind the following peculiarities:
- In the bounds of one operation, plug-in processing time is limited to two minutes. Exceeding this limit causes the TimeOutException. If more time is needed, you need to create a custom workflow.
- Plug-ins should be created in such a way that they don’t store states inside themselves. As mentioned in the SDK documentation, it’s not guaranteed that even constructors will be called each time an operation is processed because Dynamics 365 caches your plug-ins.
Let’s assume that you’ve bought Dynamics 365 and are using it to manage certain processes. At the same time, you have an instance of Monster2000 deployed and it performs some very important tasks. For some reason, it’s not possible to reassign these tasks to Dynamics 365. However, the result of Monster2000’s work is an important part of your company’s flow, and it has to be used in various Dynamics 365 services.
We could create our own application that would take the necessary data from Monster2000 and upload it via a client to Dynamics 365. This provides us with better control over imported data, but in many cases development is to time and cost-consuming.
An alternative to a custom-written solution is to use Microsoft BizTalk Server. BizTalk Server allows you to configure certain rules (either through the user interface or in code) for converting messages from one type to another. Moreover, BizTalk Server supports different endpoints.
You can find more information on BizTalk Server at:
Microsoft Dynamics 365 provides a variety of ways to expand its existing functionality, including already available solutions and all the necessary tools to write your own custom features. Custom development is more time-consuming and expensive than simply integrating an already available solution. However, any Microsoft Dynamics 365 review will tell you that available selection of ready-to-use third party components for the system is not very wide, and thus many companies that want to further tailor the system to their own needs would need to engage in custom development.
Ultimately, whether you decide to use custom written solution or an existing one, is entirely depends on the task at hand and resources that you wish to spare.