D365 CRM Intelligence – KI-Assistent für Dynamics 365

Überblick

D365 CRM Intelligence ist ein KI-Assistent für die Abfrage von Dynamics-365-CRM-Daten in natürlicher Sprache, aufgebaut auf Azure AI Foundry Agents mit Retrieval-Augmented Generation (RAG) über Azure AI Search.

Statt durch CRM-Ansichten zu navigieren und Advanced-Find-Abfragen zu bauen, stellen Nutzer einfach Fragen wie „Zeig mir offene Opportunities über 500.000 $" oder „Welche Accounts hatten seit 90 Tagen keinen Kontakt?" — und erhalten fundierte Antworten mit Quellenangaben, basierend auf Live-Daten aus Dynamics 365, inklusive Zitaten, die direkt auf die ursprünglichen CRM-Datensätze verlinken.

Zentrale Aspekte:

• Azure AI Foundry Agent (gpt-4.1) auf der neuen Versioned-Agents-Oberfläche (Responses API), orchestriert in .NET über das Microsoft Agent Framework — den Nachfolger von Semantic Kernel
• Hybrides Retrieval (Vektor + Keyword) über Azure AI Search, als Built-in-Tool an den Agent angebunden, mit Vektoren aus text-embedding-3-large und einem integrierten Vectorizer, der die Suchanfrage zur Laufzeit selbst einbettet
• Live-Zugriff auf die Dataverse Web API über Agent Function Tools — exakte Umsatzzahlen, Pipeline-Summen und aktuelle Aktivitäten direkt aus Dynamics 365
• Enterprise-Sicherheit von Grund auf: Endbenutzer-Authentifizierung mit Microsoft Entra ID, Rate Limiting pro Benutzer, IP-beschränkter API-Zugang sowie DefaultAzureCredential / Managed Identity durchgängig — keine API-Keys
• ASP.NET Core 10 Minimal API, die Agent-Antworten per Server-Sent Events an ein Next.js-16-Frontend streamt, inklusive Live-Citation-Events
• Durchgängiges Distributed Tracing mit OpenTelemetry und Application Insights — jeder Chat-Turn vom HTTP-Request bis zum einzelnen Tool-Aufruf; Agent-Traces zusätzlich im Azure AI Foundry Portal sichtbar
• Infrastructure as Code mit Terraform (Multi-Environment) und Azure DevOps CI/CD mit Workload Identity Federation

Architektur

High-Level-Architektur

Next.js 16 Frontend (Chat-UI)
  • App Service Built-in Auth (Entra ID, nur zugewiesene Benutzer)
  • Chat-Proxy leitet das Bearer Token des Benutzers weiter
       │
       │ HTTPS + SSE
       ▼
ASP.NET Core 10 Minimal API
  • Bearer-Token-Validierung (Microsoft.Identity.Web)
  • Rate Limiting pro Benutzer · IP-beschränkter Zugang
       │
       │ Managed Identity
       ▼
Azure AI Foundry Agent (gpt-4.1, versioniert, Responses API)
  • Microsoft Agent Framework (.NET)
  ├── Built-in-Tool → Azure AI Search (hybrides Retrieval: Vektor + Keyword)
  └── Function Tools → Dataverse Web API (Live-CRM-Daten)

Background Indexing Service (IHostedService)
  • Dataverse Delta-Sync → Dokumentkomposition → text-embedding-3-large → AI Search
       ▲
       │ OData REST
Dynamics 365 / Dataverse
  Accounts · Kontakte · Opportunities · Cases · Aktivitäten

Der Agent kombiniert zwei Datenzugriffspfade: semantisches Retrieval über indexierte CRM-Daten für breite, unscharfe Fragen — und Live-Aufrufe der Dataverse Web API für Fragen, die exakte Werte, Aggregationen oder minutenaktuelle Daten erfordern.

Agentic RAG

Die Lösung geht über klassisches RAG hinaus, indem der Agent selbst entscheidet, wie er jede Frage beantwortet:

• Azure AI Search als Built-in-Agent-Tool — hybrides Retrieval (Vektor + Keyword) über CRM-Datensätze, eingebettet mit text-embedding-3-large
• Dataverse Function Tools — typisierte .NET-Methoden, die der Agent für Live-Daten aufruft: Account-Details, offene Opportunities mit exakten Schätzwerten, Pipeline-Summen, aktuelle Aktivitäten und Cases
• Trennschärfe zwischen beiden Pfaden — die Agent-Instructions legen fest, dass jede numerische Aggregation aus den Function Tools stammen muss und niemals aus Indexdokumenten berechnet werden darf; der Index liefert Kontext, Dataverse liefert Zahlen
• Fundierte Quellenangaben — der Agent zitiert die verwendeten Suchdokumente; ein Citation Resolver löst sie zu Deep Links auf die ursprünglichen Dynamics-365-Datensätze auf, die in der Chat-UI angezeigt werden
• Inkrementelle Hintergrund-Indexierung — ein IHostedService fragt Dataverse in konfigurierbaren Intervallen ab (Standard: alle 15 Minuten) und verarbeitet über eine High-Watermark nur geänderte Datensätze, sodass die Indexierungskosten proportional zum Änderungsvolumen im CRM bleiben

Dieser hybride Ansatz liefert semantische Breite und transaktionale Genauigkeit zugleich — ein Muster, das sich direkt auf Enterprise-Szenarien mit CRM, ERP oder Wissensdatenbanken übertragen lässt.

Sicherheitsmodell

Die Sicherheit folgt einem Enterprise-First-Design ohne Schlüssel:

• Endbenutzer-Authentifizierung mit Microsoft Entra ID: App Service Built-in Authentication auf dem Frontend, beschränkt auf explizit zugewiesene Benutzer; der Chat-Proxy leitet das Access Token des Benutzers weiter, und die API validiert jedes Bearer Token mit Microsoft.Identity.Web — sie vertraut niemals ihrer Netzwerkposition
• DefaultAzureCredential / Managed Identity für sämtliche Service-zu-Service-Kommunikation (Azure AI Foundry, AI Search, Dataverse) — keine API-Keys im gesamten System; derselbe Code läuft lokal über Azure-CLI-Credentials
• Ein einziges Credential im System, das Client Secret der Frontend-App-Registrierung für App Service Built-in Authentication. Es wird von Terraform erzeugt und ausschließlich von der Authentifizierungsplattform gelesen — der Anwendungscode sieht es nie
• Fixed-Window Rate Limiting pro Benutzer auf dem Chat-Endpunkt, um die Modellkapazität gegen einzelne Aufrufer zu schützen
• IP-beschränkter API-Zugang — die API akzeptiert nur Traffic von den ausgehenden Adressen des Frontends, alles andere wird per Default-Deny blockiert
• Konfiguration ohne Secrets: alle Einstellungen sind Umgebungsvariablen, gebunden über IOptions<T>

Streaming & User Experience

• Die ASP.NET Core 10 Minimal API streamt Agent-Antworten per Server-Sent Events mit typisierten Events: Text-Deltas, Zitate sobald sie auftauchen und ein Completion-Event
• Das Next.js-16-Frontend (TypeScript, Tailwind CSS, App Router) rendert Tokens direkt beim Eintreffen und zeigt aufgelöste Quellenangaben mit Links nach Dynamics 365
• Mehrstufige Konversationen werden serverseitig verwaltet: der Verlauf liegt im Conversation Store der Responses API, der Client hält lediglich den jeweils aktuellen Conversation-Identifier und sendet ihn beim Folge-Turn zurück — kein Chat-Verlauf im Browser
• Abbruch propagiert durch die gesamte Kette: bricht der Nutzer eine Antwort ab, beendet das Abort-Signal den Proxy-Request und damit den laufenden Agent-Run

Observability

• OpenTelemetry-Instrumentierung über API, Agent-Orchestrierung und Indexierungs-Pipeline hinweg, mit eigenen Activity Sources für Agent-Runs und Indexierungszyklen
• Application Insights als Distributed-Tracing-Backend: jeder Chat-Turn ist als Span-Baum nachvollziehbar — Agent-Run, Modellaufrufe inklusive Token-Verbrauch, Tool-Ausführungen und die zugrunde liegenden Dataverse-Requests
• Strukturiertes Logging über ILogger<T> mit semantischen Properties durchgängig
• Agent-Traces zusätzlich direkt im Azure AI Foundry Portal sichtbar

Infrastruktur & CI/CD

• Terraform provisioniert sämtliche Azure-Ressourcen — Foundry-Projekt, Modell-Deployments, AI Search, App Services, Entra-ID-App-Registrierungen, RBAC — über dev, staging und production, mit Remote State in Azure Blob Storage
• Drei Azure-DevOps-Pipelines: CI (Solution-Build mit -warnaserror, Frontend-Lint und Production-Build, Terraform fmt und validate bei jedem PR), Infrastruktur (terraform plan bei PRs, freigabepflichtiges apply, promotet dev → staging → production) und Release (Zip Deploy der API und des Next.js-Standalone-Builds — ohne Container)
• Workload Identity Federation durchgängig — kurzlebige OIDC-Tokens statt gespeicherter Credentials, mit getrennten Pipeline-Identitäten: eine Infrastruktur-Identität mit Entra-Directory-Rechten und eine reine Deploy-Identität, die ausschließlich Web-Apps ausliefern kann

Grenzen des aktuellen Stands

Der Assistent läuft Ende zu Ende in einer deployten Azure-Umgebung. Für einen produktiven Rollout mit echten CRM-Daten fehlen Bausteine, die hier bewusst offen benannt sind:

• Kein Security Trimming. Der Agent liest mit der Managed Identity der API, nicht im Kontext des angemeldeten Benutzers. Alle authentifizierten Nutzer sehen denselben Datenbestand; das Zeilen-Berechtigungsmodell von Dynamics 365 greift nicht durch. Der Weg dorthin wäre On-Behalf-Of für Dataverse-Aufrufe und ein security_ids-Feld im Suchindex mit search.in()-Filter.
• Löschungen werden nicht propagiert. Der Delta-Sync erkennt über eine High-Watermark geänderte und neue Datensätze, aber keine gelöschten. Dataverse Change Tracking wäre der native Weg und löst zugleich die Persistenz der Watermark.
• Keine Evaluation-Pipeline. Groundedness und Citation Faithfulness werden nicht automatisiert gemessen. Prompt-, Modell- und Retrieval-Änderungen sind damit nicht regressionsgesichert.
• Read-only. Das System schreibt nicht nach Dynamics 365 zurück. Schreibzugriffe würden ein Bestätigungsmodell, einen Audit Trail und eine andere Autorisierungsarchitektur erfordern.

Eine vollständige Bewertung — 32 Einträge, jeweils klassifiziert als bewusste Scope-Grenze oder als Defekt, mit Impact und Lösungsweg, plus ein dreistufiger Pfad zur Produktionsreife — liegt im Repository unter PRODUCTION-READINESS.md.

Built With

Einordnung

Dieses Projekt zeigt, wie man produktionsreife KI-Agenten auf dem Microsoft-Stack baut:

• Agentic RAG mit hybridem Vektor-Retrieval, Live-Zugriff auf Enterprise-APIs und fundierten Quellenangaben
• schlüssellose, identitätsbasierte Sicherheit vom Browser bis zum KI-Service
• Streaming-Agent-UX mit modernem .NET und Next.js
• durchgängiges Distributed Tracing und Infrastructure as Code von Anfang an

Die Architektur ist direkt auf Enterprise-Szenarien übertragbar, in denen KI-Assistenten authentifizierten, nachvollziehbaren Zugriff auf Geschäftsdaten in Dynamics 365, Dataverse oder vergleichbaren Systemen benötigen. Die Autorisierung auf Datenebene ist dabei bewusst als eigener Schritt ausgewiesen — siehe Grenzen des aktuellen Stands.