Using Plugin Trace Logs - Rishan Solutions

In enterprise applications built on Microsoft’s Dataverse and Dynamics 365, business logic is often extended using plugins—custom code that executes in response to system events like record creation, update, or deletion. While powerful, plugins can sometimes fail silently, leading to frustrating debugging sessions.

That’s where Plugin Trace Logs come in. These logs provide detailed insights into the internal execution of plugin code and are indispensable for diagnosing and resolving issues in complex systems.

In this article, we’ll explore what plugin trace logs are, how to enable and use them, best practices for logging, and how they can transform your troubleshooting process.

1. What Are Plugin Trace Logs?

Plugin Trace Logs are diagnostic logs generated by the Dataverse plugin execution engine. They capture information about:

Plugin execution flow
Exception details
System context at runtime
Custom traces written via code

They are an invaluable tool for developers, system administrators, and support teams working in Dynamics 365 or Power Platform environments.

2. Why Use Plugin Trace Logs?

Here’s why trace logs matter:

Troubleshooting Errors: When plugins throw errors, trace logs help pinpoint the root cause.
Understanding Context: Logs show which user triggered the plugin, which entity was affected, and which message was processed.
Performance Tuning: Logs include execution duration, helping you identify performance bottlenecks.
Debugging in Production: Unlike breakpoints, trace logs work in production environments without interrupting operations.
Audit Trails: Plugin logs can be reviewed later for forensic analysis of issues.

3. How Plugin Execution Works in Dynamics 365

When a record is created, updated, deleted, or when a message (like Assign, SetState, etc.) is processed, plugins can be triggered. These plugins:

Run synchronously or asynchronously
Are configured to run pre-validation, pre-operation, or post-operation
Operate in sandbox or full trust

The plugin execution pipeline creates opportunities to log runtime behavior using tracing services, which feed into plugin trace logs.

4. Enabling Plugin Trace Logging

Before you can use trace logs, you must enable logging in the Power Platform Admin Center or Dynamics 365 Settings.

Steps to Enable Plugin Trace Logs:

Navigate to Power Platform Admin Center.
Select your environment.
Go to Settings > Product > Behavior.
Under Plugin and custom workflow activity tracing, select one of:
- Off – No logging.
- Exception Only – Logs only when an error is thrown.
- All – Logs all plugin executions (use with caution in production).

Alternatively, in classic interface:

Go to Settings > Administration > System Settings > Customization Tab.
Adjust Plugin Trace Log settings accordingly.

Caution:

Set logging to “All” only temporarily in production environments to avoid performance degradation and excessive storage use.

5. Writing to Plugin Trace Logs

You can write custom messages to the trace log using the ITracingService interface.

Sample Plugin Code:

public class SamplePlugin : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));

        try
        {
            tracingService.Trace("Plugin execution started.");

            // Main plugin logic here...

            tracingService.Trace("Plugin executed successfully.");
        }
        catch (Exception ex)
        {
            tracingService.Trace($"Exception: {ex.Message}");
            throw;
        }
    }
}

These Trace() statements appear in the plugin trace log and help you monitor the flow of execution.

6. Viewing Plugin Trace Logs

Option 1: Dynamics 365 UI

Navigate to Advanced Settings > Plugin Trace Log.
Use filters to narrow down the log entries.
Open an individual log to see details like:
- Execution ID
- Start/end time
- Message name (e.g., Create, Update)
- Execution depth
- Secure and unsecure configuration
- Tracing output
- Exception stack trace (if any)

Option 2: XrmToolBox Plugin Trace Viewer

Use the Plugin Trace Viewer tool for a more user-friendly view.
Download from the XrmToolBox.
Offers sorting, filtering, and export capabilities.

7. Anatomy of a Trace Log

Each log entry includes several important fields:

Operation Name: What event triggered the plugin (e.g., Create of Contact).
Correlation Id: Useful for tracing complex workflows involving multiple plugins or flows.
Execution Duration: Helps identify performance issues.
Depth: Indicates recursion level (helps detect infinite loops).
Custom Trace Output: All tracingService.Trace() messages.
Exception Details: Complete stack trace of unhandled errors.

8. Best Practices for Plugin Tracing

a. Keep Logs Clean and Relevant

Avoid verbose logging in production.
Trace key checkpoints, not every line of code.

b. Trace Input and Output Parameters

Log important values like entity IDs, field values, and configurations.

Entity entity = (Entity)context.InputParameters["Target"];
tracingService.Trace("Target Entity: {0}, ID: {1}", entity.LogicalName, entity.Id);

c. Use Try-Catch Blocks Around Logic

Always wrap logic in try-catch blocks and log exceptions for diagnostics.

d. Use Conditional Tracing

Enable tracing only when debugging by checking configuration or custom flags.

if (pluginContext.Depth == 1)
    tracingService.Trace("First execution only");

e. Limit Tracing in Loops

Avoid writing trace logs inside loops or recursion unless necessary.

9. Using Logs for Debugging

Plugin trace logs help you:

Identify plugin timing and execution order
Discover plugin recursion issues
Debug misconfigured steps or missing parameters
Analyze unexpected nulls or type casting errors

Here’s a typical debugging workflow:

Reproduce the issue.
Locate the latest trace log entry.
Analyze the trace output.
Match correlation IDs if multiple plugins are involved.
Fix the issue and re-deploy.
Test and verify new trace output.

10. Managing Trace Log Retention

Trace logs are stored in the PluginTraceLog table in Dataverse. Without cleanup, this table can grow quickly.

Options to Manage Logs:

Retention Policy: No built-in auto-cleanup exists. Use scheduled flows or jobs.
Automated Cleanup: Use Power Automate or scheduled plugins to delete logs older than X days.

Example: Power Automate flow to delete PluginTraceLog entries over 30 days old.

11. Common Issues and Troubleshooting

a. Plugin Error Without Trace Log

Ensure tracing is enabled (at least to Exception Only).
Check if plugin is running asynchronously; logs may take time to appear.

b. Trace Log Missing Details

Developer forgot to use ITracingService.
Trace calls were made outside the try-catch block.

c. Logs Consuming Storage

Use retention or export/archive processes.
Set tracing to Exception Only for production.

12. Alternatives and Complementary Tools

While plugin trace logs are powerful, you can also consider:

Telemetry with Application Insights: For real-time monitoring and central logging.
Custom Logging Tables: For permanent storage of key plugin events.
Power Platform CoE Kit: Offers visibility into plugin and app usage trends.
Azure Monitor: Can ingest logs from Power Platform via connectors.