Logo
  • English icon
  • German icon
D365 CRM Intelligence Architecture – Azure AI Foundry Agent with RAG over Dynamics 365 data

D365 CRM Intelligence – AI Assistant for Dynamics 365

azure-ai-foundryagentic-ragdynamics-365azure-ai-searchmicrosoft-agent-frameworkdotnetnextjsterraform

Overview

D365 CRM Intelligence is an AI assistant for natural language querying of Dynamics 365 CRM data, built on Azure AI Foundry agents with retrieval-augmented generation (RAG) over Azure AI Search.

Instead of navigating CRM views and building advanced-find queries, users simply ask questions like "Show me open opportunities over $500k" or "Which accounts haven't had contact in 90 days?" — and receive grounded, cited answers drawn from live Dynamics 365 data, with citations linking back to the original CRM records.

Key aspects include:

  • Azure AI Foundry agent (gpt-4.1) on the new versioned-agents surface (Responses API), orchestrated in .NET via the Microsoft Agent Framework — the successor to Semantic Kernel
  • Hybrid retrieval (vector + keyword) over Azure AI Search, connected to the agent as a built-in tool, with vectors from text-embedding-3-large and an integrated vectorizer that embeds the query itself at search time
  • Live Dataverse Web API access through agent function tools — exact revenue figures, pipeline totals, and recent activities straight from Dynamics 365
  • Enterprise security by design: Microsoft Entra ID end-user authentication, per-user rate limiting, IP-restricted API ingress, and DefaultAzureCredential / Managed Identity throughout — no API keys
  • ASP.NET Core 10 minimal API streaming agent responses to a Next.js 16 frontend via Server-Sent Events, including live citation events
  • End-to-end distributed tracing with OpenTelemetry and Application Insights — every chat turn from HTTP request down to the individual tool call; agent traces also visible in the Azure AI Foundry portal
  • Infrastructure as Code with Terraform (multi-environment) and Azure DevOps CI/CD using workload identity federation

Architecture

High-Level Architecture

Next.js 16 Frontend (Chat UI)
• App Service built-in auth (Entra ID, assigned users only)
• Chat proxy forwards the user's bearer token
│ HTTPS + SSE
ASP.NET Core 10 Minimal API
• Bearer token validation (Microsoft.Identity.Web)
• Per-user rate limiting · IP-restricted ingress
│ Managed Identity
Azure AI Foundry Agent (gpt-4.1, versioned, Responses API)
• Microsoft Agent Framework (.NET)
├── Built-in tool → Azure AI Search (hybrid retrieval: vector + keyword)
└── Function tools → Dataverse Web API (live CRM data)
Background Indexing Service (IHostedService)
• Dataverse delta sync → compose documents → text-embedding-3-large → AI Search
│ OData REST
Dynamics 365 / Dataverse
Accounts · Contacts · Opportunities · Cases · Activities

The agent combines two data access paths: semantic retrieval over indexed CRM data for broad, fuzzy questions, and live Dataverse Web API calls for questions that need exact values, aggregations, or up-to-the-minute accuracy.


Agentic RAG

The solution goes beyond classic RAG by letting the agent decide how to answer each question:

  • Azure AI Search as a built-in agent tool — hybrid (vector + keyword) retrieval over CRM records embedded with text-embedding-3-large
  • Dataverse function tools — typed .NET methods the agent calls for live data: account details, open opportunities with exact estimated values, pipeline totals, recent activities and cases
  • A hard boundary between the two paths — the agent instructions require every numeric aggregate to come from a function tool and forbid computing one from index documents; the index supplies context, Dataverse supplies figures
  • Grounded citations — the agent cites the search documents it used; a citation resolver maps them back to deep links into the original Dynamics 365 records, rendered in the chat UI
  • Incremental background indexing — an IHostedService polls Dataverse on a configurable schedule (default: every 15 minutes) using a high-watermark, so only changed records are re-embedded and indexing cost stays proportional to CRM change volume

This hybrid approach delivers both semantic breadth and transactional accuracy — a pattern directly applicable to enterprise CRM, ERP, and knowledge-base scenarios.


Security Model

Security follows an enterprise-first, keyless design:

  • Microsoft Entra ID end-user authentication: App Service built-in authentication on the frontend, restricted to explicitly assigned users; the chat proxy forwards the user's access token, and the API validates every bearer token with Microsoft.Identity.Web — it never trusts its network position
  • DefaultAzureCredential / Managed Identity for all service-to-service communication (Azure AI Foundry, AI Search, Dataverse) — no API keys anywhere in the system; the same code runs locally via Azure CLI credentials
  • Exactly one credential exists, the frontend app registration's client secret used by App Service built-in authentication. Terraform generates it and the authentication platform is its only consumer — application code never sees it
  • Per-user fixed-window rate limiting on the chat endpoint, protecting model capacity against any single caller
  • IP-restricted API ingress — the API only accepts traffic from the frontend's outbound addresses, default-deny otherwise
  • Secrets-free configuration: all settings are environment variables bound via IOptions<T>

Streaming & User Experience

  • The ASP.NET Core 10 minimal API streams agent responses via Server-Sent Events with typed events: text deltas, citations as they surface, and a completion event
  • The Next.js 16 frontend (TypeScript, Tailwind CSS, App Router) renders tokens as they arrive and displays resolved citations with links into Dynamics 365
  • Multi-turn conversations are service-backed: history lives in the Responses API conversation store, and the client holds nothing but the current conversation identifier, echoing it on the next turn — no chat history in the browser
  • Cancellation propagates end to end: aborting an answer in the browser cancels the proxy request and, with it, the running agent turn

Observability

  • OpenTelemetry instrumentation across the API, agent orchestration, and the indexing pipeline, with dedicated activity sources for agent runs and indexing cycles
  • Application Insights as the distributed tracing backend: every chat turn is a readable span tree — agent run, model calls with their token usage, tool executions, and the underlying Dataverse requests
  • Structured logging via ILogger<T> with semantic properties throughout
  • Agent traces also visible directly in the Azure AI Foundry portal

Infrastructure & CI/CD

  • Terraform provisions all Azure resources — Foundry project, model deployments, AI Search, App Services, Entra ID app registrations, RBAC — across dev, staging, and production, with remote state in Azure Blob Storage
  • Three Azure DevOps pipelines: CI (solution build with -warnaserror, frontend lint and production build, Terraform fmt and validate on every PR), infrastructure (terraform plan on PRs, approval-gated apply promoted dev → staging → production), and release (zip deploy of the API and the Next.js standalone build — no containers)
  • Workload identity federation throughout — short-lived OIDC tokens instead of stored credentials, with split pipeline identities: an infrastructure identity holding Entra directory rights, and a deploy-only identity that can do nothing but ship web apps

Current Limitations

The assistant runs end to end in a deployed Azure environment. Taking it to production with real CRM data requires building blocks that are deliberately stated here rather than glossed over:

  • No security trimming. The agent retrieves with the API's managed identity, not in the context of the signed-in user. Every authenticated user sees the same data, and the Dynamics 365 row-level permission model does not carry through. Closing this means on-behalf-of token exchange for Dataverse calls and a security_ids field on indexed documents applied as a search.in() filter.
  • Deletions do not propagate. The delta sync detects created and modified records through a high-watermark, but not deleted ones. Dataverse change tracking is the native answer and makes the watermark durable at the same time.
  • No evaluation pipeline. Groundedness and citation faithfulness are not measured automatically, so prompt, model, and retrieval changes ship without regression protection.
  • Read-only. The system does not write back to Dynamics 365. Write access would require a confirmation model, an audit trail, and a different authorization posture.

A full assessment — 32 entries, each classified as a deliberate scope boundary or a defect, with impact and resolution, plus a three-stage path to production — lives in the repository at PRODUCTION-READINESS.md.


Built With


Scope

This project demonstrates how to build production-grade AI agents on the Microsoft stack:

  • agentic RAG combining hybrid vector retrieval, live enterprise APIs, and grounded citations
  • keyless, identity-based security from the browser all the way to the AI service
  • streaming agent UX with modern .NET and Next.js
  • end-to-end distributed tracing and Infrastructure as Code from day one

The architecture is directly transferable to enterprise scenarios where AI assistants need authenticated, auditable access to business data in Dynamics 365, Dataverse, or similar systems. Authorization at the data layer is deliberately called out as its own step — see Current Limitations.