AI in CRM: What I Actually Use, and What I Don't Trust Yet

A confession about vantage point#

I'm not a machine-learning engineer. I don't train models, and I'm suspicious of CRM architects who suddenly claim they do. My vantage point is different: I build and rescue Dynamics 365 platforms, which means I get to see where AI features actually land on real systems, and where they sit enabled, unused, and quietly costing something.

That second category is more common than any vendor deck admits. So this is not a "top use cases for AI in CRM" article. It's what I've personally seen work, fail, and lurk.

The Copilot tables nobody had ever used#

While auditing Dataverse Search on a credit-management platform (35,000+ active cases, 30+ users, years of incremental development), I reconciled every table enabled for the global search index. Among the 51 indexed tables were Copilot Studio tables. Also Field Service tables, and Customer Service entities the firm had never deployed.

Nobody had decided to index them. They arrived with the platform, got swept into the index, and sat there adding weight to every search operation. The cleanup plan projected the index could shrink by more than half, and a meaningful slice of that was AI-adjacent furniture from features no one had switched on.

That's my first honest finding about AI in CRM: before it transforms anything, it ships as tables, settings, and consumption meters in your environment. Platform owners should audit what AI features actually cost them today, in index weight, storage, and licensing, before debating what AI might deliver tomorrow.

Your copilot is only as good as your timeline#

The same platform had a bug I've written about elsewhere: the Outlook add-in duplicated tracked emails, so case timelines showed conversations twice.

Now imagine pointing a copilot at that. "Summarize this case" reads a timeline where every customer email appears two times. The summary comes back confidently wrong about how often the customer followed up. No model fixes this, because the model is doing its job: faithfully summarizing corrupted input.

This is why I keep insisting that data quality work is AI readiness work, and not as a slogan. The deduplication flow we built for that platform was justified on user-experience grounds, but its biggest long-term payoff may be that any future AI feature reading those timelines will read the truth. If your CRM data is duplicated, stale, or entered three different ways by three different teams, an AI layer doesn't hide that. It amplifies it, fluently.

Agents will hit the same wall users do#

On that platform, case handlers were deleting workflow-critical tasks despite UI locks, so we enforced the rule in a PreValidation plugin: server-side, impossible to bypass regardless of whether the delete came from a form, a grid, or the Web API.

I think about that plugin every time someone demos an autonomous agent acting inside a CRM. An agent is just another caller. If your business rules live in UI customizations and training documents, an agent will violate them at machine speed and with perfect confidence. This client operated in debt recovery; there, that's a compliance incident.

The encouraging flip side: Dataverse already has the right enforcement layer. A plugin in the execution pipeline doesn't care who's calling. Human, integration, copilot, or agent: same validation, same rejection. If you're preparing a D365 platform for agents, the practical work is moving every invariant you care about into server-side enforcement, where AI can't talk its way past it. Prompt engineering comes a distant second.

Where AI changed my own work#

Here's the part I can vouch for without a single asterisk: AI-assisted engineering has changed how I deliver D365 projects more than any platform AI feature has.

The plugin I just described was scaffolded, built, signed, and deployed entirely from macOS with dotnet and pac CLI, a workflow I worked out with an AI assistant alongside, including the undocumented Dataverse behaviors we hit on the way (solution-prefix requirements on PluginPackage fields, first-time registration quirks). The cross-platform recipe that came out of it is now reused across my projects.

On a logistics program where I authored specifications for 60+ features and 40+ integration DTOs, AI assistance compressed the mechanical parts of documentation work (first drafts, structure, consistency checks) and left the judgment calls where they belong. The specs still needed every architectural decision made by a human who'd sat in the workshops. But the blank-page tax is gone, and across a multi-month design phase that compounds into real time.

Notice neither of those is "AI in CRM" as marketed. No copilot button was involved. The value showed up in the engineering process around the platform, not in the platform's AI SKU.

What I'd actually do, in order#

If you run a D365 platform and the AI mandate has arrived from above, the sequence that survives contact with reality looks like this: audit what AI-related features already exist in your environment and what they cost. Fix the data quality problems that would poison any model reading your records. Duplicates first, since they're the most visible. Move your real business rules into server-side enforcement. Then, and only then, pilot retrieval-style features such as summarization, lookup, and drafting, where a wrong answer wastes a minute instead of triggering a regulatory event.

Boring order. But I've watched the reverse order get demoed, applauded, and reverted.