What it does

ITracingService collects the messages your plug-in or custom workflow activity writes at runtime and the platform stores them as rows in the PluginTraceLog table. It's the only first-party way to see inside sandboxed code after it has run.

Key facts

• Logging is off by default. The switch is the PluginTraceLogSetting column on the Organization table: 0 = Off, 1 = Exceptions, 2 = All. You can set it in System Settings > Customization, in the Plug-in Registration tool under Settings, or programmatically.
• Trace calls are batched and written as one row after the code finishes or throws — not line by line as it runs.
• The MessageBlock column holds 10 KB of text. Past that the system drops the oldest lines, so a chatty plug-in silently loses the start of its own trace.
• Rows live 24 hours. A bulk delete job runs daily to clear anything older.
• If the plugintracelogbase table passes 100 GB, Microsoft may disable trace logging on the environment for you.
• Trace rows survive a transaction rollback, which is what makes them useful for diagnosing failures.
• Read access to MessageBlock, Configuration and SecureConfiguration is restricted to System Administrator (added September 2026). Everyone else gets null for those three columns, whether they read through the Plug-in Trace Log tile, the Web API or a community tool. The role counts whether it's assigned directly or inherited through a team. Every other column — TypeName, MessageName, PrimaryEntity, ExceptionDetails — still follows normal table privileges.
• With the setting on Exceptions, a synchronous failure also surfaces in the user's error dialog (Download Log File), and an asynchronous one in the System Job record's Details.

When to use / skip

Turn it on to debug a specific problem, then turn it off. On "All" in a busy environment it writes a row per plug-in execution and eats storage fast. It's a debugging tool, not an audit trail or a monitoring feed — for ongoing health use the plug-in analytics in the admin centre instead.

Configuration decisions

• Off, Exceptions or All. Exceptions is the sensible standing setting for a non-production environment; Off is the right answer for production unless you're actively chasing something.
• Who gets System Administrator, now that the trace content is gated on it. Handing out the role to let a developer read traces is a bad trade.
• Whether your trace messages should contain what they currently contain. Plenty of plug-ins log connection strings and record payloads on the assumption nobody reads them.
• Leave the daily bulk delete job alone. Disabling it or stretching the interval is a documented way to cause performance problems later.

Gotchas

• The System Administrator restriction changes existing behaviour, not just new environments. A developer or support user who could read traces last month now sees null in MessageBlock and will report it as "tracing has stopped working" — the row is there, the content isn't.
• A community tool like Plugin Trace Viewer will look broken for the same reason. Nothing is wrong with the tool.
• The 10 KB truncation removes the oldest lines, so the "it never got to my code" conclusion is often wrong — the early trace lines were dropped.
• Turning logging on and seeing nothing usually means the code never called Trace, not that logging failed. There's no warning either way.
• 24-hour retention means a failure reported on Monday about something that happened on Friday has no trace to look at. Ask people to capture the row, not the screenshot of the error.

Consultant notes

• Agree during design where secrets live. Now that secure configuration is only readable by System Administrator, teams tend to assume it's safe to put credentials in a trace message. It isn't — it's one role assignment away from visible, and it persists for 24 hours.
• Expect this restriction to land as a support ticket rather than a release note. Warn the client's developers before they hit it, particularly anyone using XrmToolBox daily.
• On a handover, check the trace setting before you check anything else. Finding an environment sitting on "All" for months explains a surprising amount of storage consumption and a little of the write latency.
• Don't let trace logging become the client's error-handling strategy. If the only way to find out a nightly integration failed is to read traces within 24 hours, the design needs a real failure path.

---

Worth revisiting if Microsoft extends the restricted column list, or changes the 24-hour retention.