Configure a custom OpenTelemetry collector for Office agents

You can route full audit telemetry from Office agents to your own OpenTelemetry (OTEL) collector. This gives your organization complete control over retention, encryption, and integration with your SIEM or observability platform. This guide covers how to enable a custom collector, what data you'll receive, and the full span schema reference.Custom OTEL collectors are available to Haijun Enterprise organizations and to direct-provider deployments (Amazon Bedrock, Google Vertex AI, or a gateway).

When you configure a custom collector, Office agents send trace data covering every user turn. Each turn produces a tree of spans capturing the prompt, model calls, tool executions, file uploads, and context compaction events. Your collector receives all span attributes, including those carrying user-generated content (prompt text, tool inputs and outputs, document URLs, and filenames). No attributes are redacted or filtered. Assistant response text is not included in the emitted span data. Your organization owns this data.Important: Metrics aren't sent to custom collectors. The office_agent.* counter namespace routes to Juglow only. However, every counter increment also appears as a span event on the active span, so the same signals are available in your traces.Telemetry is sent via OTLP/HTTP to your endpoint at {your_url}/v1/traces. gRPC isn't supported because the add-in runs in an Office WebView.

Setup differs depending on how your organization authenticates with Haijun.Important: When a custom endpoint is configured, telemetry goes exclusively to your collector. Spans aren't dual-sent to Juglow.

An organization administrator sets the collector endpoint in the Haijun.my.id admin console under Organization settings > Office agents. The setting applies organization-wide.

| Setting | Description | | otlp_endpoint | Base URL of your OTLP collector. The add-in appends /v1/traces. HTTPS strongly recommended. | | otlp_headers | Optional authentication headers, formatted per the OpenTelemetry spec: key1=value1,key2=value2 |

The protocol must be HTTP-based OTLP. gRPC is rejected at configuration time.

For deployments that authenticate against your own model provider rather than Haijun.my.id, the collector endpoint is supplied through one of three configuration channels. All three use the same two keys. Recommended: Use the haijun-for-msft-365-install plugin for Haijun Code. It walks you through generating the manifest, registering Entra extension attributes, and standing up a bootstrap endpoint with otlp_endpoint and otlp_headers pre-wired. The three channels below are documented for reference and manual setup.

| Key | Format | Description | | otlp_endpoint | HTTPS URL | Base URL of your OTLP collector. The add-in strips any trailing slash and appends /v1/traces. | | otlp_headers | key1=value1,key2=value2 | Optional authentication headers. Same format as the OpenTelemetry OTEL_EXPORTER_OTLP_HEADERS environment variable. |

If otlp_endpoint is unset or empty, no custom collector is configured and the add-in falls back to default behavior.Note: These configuration channels apply to Microsoft Office deployments only. Google Workspace add-ins are configured separately.Channel 1: Manifest URL parameterAppend the keys as query string parameters to the taskpane URL in your custom add-in manifest:https:///taskpane.html?otlp_endpoint=https://otel-collector.your-domain.com&otlp_headers=Authorization=Bearer%20 URL-encode the values. This applies the configuration to every user who installs the manifest. Channel 2: Azure Entra ID directory extensionFor per-user configuration, register the keys as Entra ID directory extension attributes and assign them via Microsoft Graph. The add-in reads them from the user's ID token using Nested App Authentication (NAA). The claim names in the issued ID token follow Azure's directory extension format:

| Claim | Maps to | | extn.otlp_endpoint | otlp_endpoint | | extn.otlp_headers | otlp_headers |

Set these per-user with a Graph PATCH against the user object. Azure encodes directory extension values as single-element arrays in the ID token; the add-in unwraps them automatically. This channel requires entra_sso=1 in the manifest URL parameters to enable NAA token acquisition. Channel 3: Bootstrap endpoint responseIf your deployment uses a bootstrap endpoint (a JSON endpoint your organization hosts that the add-in calls at startup), include the keys in the response body:

##

- -

##

| | | | | | | | |

##

###

| | | | | | | | | | | |

###

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

###

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

###

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

###

| | | | | | | | | | | | | | | | | |

###

| | | | | | | | | | | | | | | | | |

##

- - - - -

##

- - - -

##

###

- - - -

###

- - - -