[Feature Request] Add support for Microsoft Dynamics 365

[lhirlimann]

Currently the only way to monitor on prem instances of Microsoft Dynamics 365.
Currently the only way to monitor is via system monitoring and log ingestion.
Add support to have APM style integration to see internals from the application.

[github-actions]

tl;dr: I recommend treating this as a net-new microsoft_dynamics_365 integration package focused on API/log ingestion first, and handling “APM-style internals” through the existing APM agent path where Dynamics runtime instrumentation is actually supported.

Recommendation

Build a new package (rather than extending o365/m365_defender) and phase delivery:

1. Phase 1 (in this repo): Dynamics-specific logs/events/API ingestion package.
2. Phase 2 (outside package definition): APM agent instrumentation guidance for Dynamics-hosted services if supported by the app/runtime.

Why: this repo’s integration model is input-driven collection, and existing Microsoft packages here are API/log/EventHub/CEL patterns, while APM is managed as its own integration/input type.

Findings

• No Dynamics package currently exists:
  • glob packages/*dynamics* → no matches
  • grep -RinE "dynamics 365|microsoft dynamics" packages/*/manifest.yml → no matches
• APM package is a dedicated APM-server integration, not a Dynamics-specific collector:
  • packages/apm/docs/README.md:5 — "The APM integration enables central management of APM Server with Fleet."
  • packages/apm/manifest.yml:49-51 — type: apm, "Collect application traces"
  • packages/apm/agent/input/template.yml.hbs:1 — apm-server: configuration template
• Existing Microsoft/SaaS packages in this repo follow API/log input patterns:
  • packages/o365/manifest.yml:48-53 — cel and deprecated o365audit
  • packages/m365_defender/manifest.yml:126-131 — azure-eventhub + cel
  • packages/microsoft_exchange_server/manifest.yml:42-43 — filestream
• Best scaffold for a net-new app integration is the Salesforce pattern:
  • packages/salesforce/manifest.yml:117-124 — dedicated salesforce input
  • packages/salesforce/data_stream/login/manifest.yml:4,85 — stream input + template_path
  • packages/salesforce/data_stream/login/agent/stream/salesforce.yml.hbs:1-19 — auth + polling template
• Ownership signals for triage:
  • packages/salesforce/manifest.yml:125-127 → elastic/obs-infraobs-integrations
  • .github/CODEOWNERS:362-363 → microsoft_sqlserver(_otel) owned by @elastic/obs-infraobs-integrations
  • .github/CODEOWNERS:359 and packages/microsoft_exchange_server/manifest.yml:45-47 indicate Windows-platform ownership patterns for on-prem Microsoft log integrations

Verification

Commands run in workspace:

$ ls packages | grep -i dynamics

$ grep -RinE "dynamics 365|microsoft dynamics" packages/*/manifest.yml

$ grep -n "type: apm" packages/apm/manifest.yml
49:      - type: apm

$ sed -n '44,52p' packages/apm/manifest.yml
  - name: apmserver
    title: Elastic APM Integration
    ...
    inputs:
      - type: apm
        title: Collect application traces

$ sed -n '117,127p' packages/salesforce/manifest.yml
policy_templates:
  - name: salesforce
    ...
    inputs:
      - type: salesforce
...
owner:
  github: elastic/obs-infraobs-integrations

$ sed -n '45,56p' packages/o365/manifest.yml
inputs:
  - type: cel
  - type: o365audit
owner:
  github: elastic/security-service-integrations

Detailed Action Plan

1. Scope definition: define Dynamics data sources (APIs, audit logs, app/server logs) and auth model; this determines whether to start with cel/httpjson/filestream or a dedicated input.
2. Create package skeleton: add packages/microsoft_dynamics_365/manifest.yml modeled on packages/salesforce/manifest.yml:117-127 (policy template + owner) and packages/o365/manifest.yml:48-56 (API polling style).
3. Add first data stream: create packages/microsoft_dynamics_365/data_stream/<dataset>/manifest.yml using packages/salesforce/data_stream/login/manifest.yml:1-88 as baseline (streams, vars, template_path).
4. Implement stream template: add .../agent/stream/<input>.yml.hbs following auth/polling pattern from packages/salesforce/data_stream/login/agent/stream/salesforce.yml.hbs:1-55.
5. Ingest mapping/pipeline: add fields/*.yml and elasticsearch/ingest_pipeline/default.yml for ECS mapping and normalization.
6. Docs and dashboards: add package docs and initial dashboards; mirror structure used in existing Microsoft packages (o365, m365_defender).
7. APM guidance track: document separately that deep internals/traces depend on APM agent support in the Dynamics hosting/runtime environment; this is adjacent to (not a replacement for) package-level log/API ingestion.

Related Items

Type	Link	Relevance
Issue	#18522	Current feature request
Issue	#17555	Prior Microsoft package maintenance pattern (microsoft_exchange_server)
Issue	#17561	Prior Microsoft package maintenance pattern (microsoft_sentinel)
Issue	#365	Search hit for Dynamics term, but not readable in this run due integrity restrictions
File	packages/apm/manifest.yml:49-51	Shows APM integration model (type: apm)
File	packages/apm/docs/README.md:5	Confirms APM server is centrally managed via Fleet
File	packages/salesforce/manifest.yml:117-127	Strong scaffold for net-new app integration package
File	packages/o365/manifest.yml:48-53	Example of API-polling Microsoft package approach
File	.github/CODEOWNERS:359,362-363	Ownership routing signal for Microsoft/on-prem vs observability packages

Note

🔒 Integrity filter blocked 89 items

The following items were blocked because they don't meet the GitHub integrity level.

• #365 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #16625 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17796 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18134 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17487 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17559 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #18144 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17043 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17230 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #16629 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17361 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17277 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17038 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #16937 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #8625 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #17035 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• ... and 73 more items

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.