Exception handling in Plugin in MIcrosoft Dynamics 365 Customer Engagement(CRM) using Plugin Trace log feature


Handling exceptions is an important part of any development effort.  As a developer One should always try to prevent errors or exceptions but sometimes there will be exceptions beyond control so we have to handle this type of exceptions correctly. Dynamics Customer Engagement is not different when it comes to exception handling.

Exception handling in Plug-Ins by Dynamics Customer Engagement

  • For synchronous plug-ins, whether registered in the sandbox or not, the Microsoft Dynamics 365 platform handles exceptions passed back from a plug-in by displaying an error message in a dialog of the web application user interface.
  • The exception message for asynchronous registered plug-ins is written to a System Job (AsyncOperation) record which can be viewed in the System Jobs area of the web application.
  • If your plugin runs infinite loop then restrict the plugin by context.Depth property.
  • For synchronous plug-ins, you can optionally display a custom error message in the error dialog of the web application by having your plug-in throw an InvalidPluginExecutionException exception with the custom message string as the exception Message property value. Sample code is below:
   catch (FaultException ex) 
    throw new InvalidPluginExecutionException("Err occurred.", ex.Message); 
  • For plug-ins not registered in the sandbox, the information is written to the Application event log on the server that runs the plug-in. The event log can be viewed by using the Event Viewer administrative tool. 
  •  If you throw InvalidPluginExecutionException and do not provide a custom message, a generic default message is displayed in the error dialog. It is recommended that plug-ins only pass an InvalidPluginExecutionException back to the platform.
  • If there is an exception in the plugin and the code executes in database transaction then the plugin will rollback. So exception handling needs more attention to make sure system performance doesn’t get hampered.

Earlier, plugin debugging has been a very challenging task when working with Customer Engagement online environment, due to the lack of a proper way to log error trace information. Luckily, a new feature called Plug-in Trace Log was included with Dynamics Customer Engagement 2016, which made the life of the developer easier for debugging a plugin.

The Plug-in Trace Log feature saves trace log information, similar to the information you get when an asynchronous plug-in throws an exception, with the advantage that traces log information will be available even when the plug-in doesn’t throw an exception. 

In this post, we’ll discuss how we can enable Plug-in trace log feature for an organization and how to utilize this feature for debugging any plugin.

Enabling Plug-in Trace Log for a Customer Engagement Instance

Step 1:

Navigate to Setting>Administration in your online dynamics Customer Engagement instance.

Step 2:

Open System Settings :

Step 3:

Click on Customization and select an option from enable login to plug-in trace log option.

Note: It has 3 options i.e Off, Exception and All. Meaning of each is explained below:

  • Off: Tracing turns off.
  • Exception: Trace record will get created only when the exception occurred.
  • All: Tracing record will get created for every execution of plugin, whether code throws an exception or now.

Caution: It’s recommended to turn on tracing only when it’s required. Moreover, you need to remember that if selected all, the system will create a trace log for all transactions. None would want to fill their system with unnecessary trace logs.

Select All for now to test the log tracing functionality.

Performing operation in Customer Engagement and checking trace log


We need to add the date as the prefix in the system generated auto number of Case. We’ll build and register a plugin on a pre-create event on the case.

Step 1:

Build the plugin with below case:

using System;
using Microsoft.Xrm.Sdk;
namespace TestPlugin
 public class Class1 : IPlugin
 public void Execute(IServiceProvider serviceProvider)
 #region Setup
 IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
 IOrganizationService service = ((IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory))).CreateOrganizationService(new Guid?(context.UserId));
 ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
 tracingService.Trace("Tracing Execute");
 if ((context.InputParameters.Contains("Target")) && (context.InputParameters["Target"] is Entity) )
  tracingService.Trace("Tracing if block");
  Entity entity = (Entity)context.InputParameters["Target"];
  if (entity.LogicalName.ToLower() != "incident") return;
   tracingService.Trace("Tracing try block-1");
   String sPreFix = DateTime.Now.Day.ToString()+ DateTime.Now.Month.ToString() + DateTime.Now.Year.ToString();
   tracingService.Trace("Tracing try block-2");
   entity["ticketnumber"] = sPreFix+entity.GetAttributeValue<String>("ticketnumber");
   tracingService.Trace("Tracing try block-3");
  catch (Exception ex)

Below is how your code will look:

Step 2:

Register your assembly into Customer Engagement using plugin registration tool. Also, register your step on pre-create on case entity as shown below:

Step 3:

Once step is registered, perform the desired operation. In our case, it’s case creation. On creation of case, the system will create a plug-in trace record which we can see as below by navigation to Settings>Plug-in Trace Log:

Step 4:

Open the plug-in trace record just created as a result of case creation operation. It’ll look as below:

In the Message Block on plug-in trace record, we’ll get all the traces stored for that operation through which system control passed.

In this case, as we selected all option while enabling plugin trace in system settings, trace log record got created even though no exception occurred.

Plug-in tracing is also useful when you aren’t sure from which block your control is passing through. You can identify the system control path by looking at printed traces in trace log record.

This new feature is very useful for developers to easily debug plugin code without writing any console app or depending on throw exception log files.

Remember to turn off tracing when your debugging is done.[/vc_column_text][/vc_column][/vc_row]

Leave a Reply