An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.
Hello Burg, van der (Tommy), We understand that you are using Azure Durable Functions (Python) with Application Insights. The Durable Task framework automatically logs AppRequests telemetry for orchestrator and activity executions, including properties like durabletask.type, durabletask.task.name, and durabletask.task.instance_id. You want to enrich these automatically generated telemetry items with custom properties (e.g., tenantId, caseId, businessStep).
The telemetry for orchestrators/activities is generated internally by the Durable Task framework. Unlike .NET, the Python SDK does not expose Telemetry Initializers or Processors for Durable Functions. You can enrich spans/events you create, but not those automatically created by Durable Functions.
This is why your attempts with Telemetry Initializers or Diagnostic Settings didn’t affect the durabletask telemetry.
Yes, it is not possible to directly modify the auto‑generated Durable Functions Request telemetry items in Application Insights when using Python. The Durable Task framework emits those entries internally, and the Python SDK does not expose a Telemetry Initializer/Processor hook like .NET does.
What you can do is enrich the current distributed tracing span that Durable Functions creates when you enable distributed tracing. Application Insights will then record your custom attributes as customDimensions alongside the durabletask properties.
What you can try is you can enable Durable Functions Distributed Tracing (V2) in host.json and then enrich the active OpenTelemetry span inside your Python orchestrators and activities using trace.get_current_span().set_attribute(...). The Functions host creates the span for each Durable execution and propagates the trace context to the Python worker, allowing your code to attach business metadata such as tenantId, caseId, or workflowStep. Application Insights captures these attributes as customDimensions on worker-emitted span/trace telemetry, and because they share the same operation_Id as the Durable Request telemetry, they are automatically correlated in end-to-end traces and can be queried together, even though the host-generated Request record itself is not modified.
Hope this helps. and please feel free to reach out if you have any further questions. Thanks