Copilot and SharePoint: fix the library first

Grounding a Copilot agent on SharePoint: what actually breaks

Pointing an agent at a SharePoint site takes about ten minutes. Pick the site, save, ask a question, get an answer. Everyone's impressed.

Then you ask something you already know the answer to, and it tells you something that was true in 2021.

I've done SharePoint work since long before any of this arrived, and what strikes me is how the old problems have suddenly become expensive. Nobody much cared that the expenses policy lived in six places. Now it's why your agent gives people the wrong expenses answer.

Versions. The agent finds one copy and answers from it, with complete confidence either way. It has no idea FINAL_v3_updated_new is the real one. Pick the authoritative copy, archive the rest, ground only on the place you trust.

Scanned PDFs. If there's no text layer, the file doesn't exist as far as the agent is concerned. That usually includes your signed contracts — the documents people most want to ask about. Check a sample before promising anything.

Permissions. The agent honours SharePoint permissions, which is what you want. The catch is the reverse: anything people could already see is now genuinely findable. Search used to be bad enough that oversharing stayed invisible. That gap is gone. Run a permissions review before you switch anything on, not after someone surfaces the salary spreadsheet in a chat window.

Metadata and file names. Empty columns are context the model doesn't get. You don't need a taxonomy project — a Status column with Draft, Current and Superseded, actually maintained, does most of the work. Same with drafts sitting in the same folder as approved documents. Separate them, or ground only on the finished material.

What this means for your estimate. Roughly two days on the agent, a few weeks on the library. Say that during scoping rather than discovering it halfway through.

It usually lands better than you'd think. Most organisations know their documents are a mess — they've just never had a reason good enough to fix it. This is the first time anyone's been willing to pay for it.

Thanks for reading this article. Hope this Article will help you. Cheers!!!

#Dynamics365 #PowerPlatform #MicrosoftCopilot #DynamicsCRM #CopilotStudio #Dataverse #AIDeveloper #DynamicsAIEngineer #HireAIEngineer #AIEngineer #D365Consultant #CRMDeveloper #AIAgents #MSDyn365

Before you switch Copilot on, spend a week in your data. Here's what I'd check.

If you're about to switch Copilot on, spend a week in your data first.

None of what follows is exciting. That's rather the point.

Start with your description fields. Copilot can only summarise what's actually there, so if half your cases have a subject line and nothing else, people get summaries that tell them nothing and stop opening them by week two.

Then your duplicates. The model has no idea which account record is the real one. It'll pick one anyway and sound completely sure about it.

Have a look at your column names too. Anything still called new_field1 needs renaming, or at least a description, because that text is what the model reads when it's working out what a field means.

Same with the ten years of closed records nobody ever archived. Leave that lot in and you'll get answers pulled from deals that died in 2018.

Watch for free text where a choice column should be. "In Progress", "in progress" and "InProg" are three different things to anything reading them.

And read a sample of your notes and attachments before you make them a knowledge source. A surprising amount of what's in there is people venting about customers.

Nobody signs off a budget for any of this. It isn't the AI project anyone pictured. But it's most of the difference between a pilot that gets extended and one that dies quietly in month three.

What's the worst data you've had to switch AI on top of?

Related: Copilot in Dynamics 365 — what it actually does

Thanks for reading this article. Hope this Article will help you. Cheers!!!

#Dynamics365 #PowerPlatform #MicrosoftCopilot #Dataverse #DataQuality #AIDeveloper

Is the D365 developer job changing? (plugins vs agents)

Someone asked me last week if plugin development is dead.

It isn't. But the shape of the work has definitely moved.

A few years ago most of my time went into plugins, JavaScript, custom workflow activities. Making the platform do things it wouldn't do on its own. A fair chunk of that is now either configuration, or an agent action, or Copilot handles it well enough that nobody asks for it any more.

What's replaced it isn't easier, just different. Data modelling matters more than it ever did, because agents inherit whatever mess you left in the schema. Security is back at the centre of every conversation. And a surprising amount of my week goes on explaining what the AI can't do, which is a strange skill to have picked up.

If you're worried about it, here's the thing I'd hold on to: deterministic logic still belongs in plugins. Anything that has to run the same way every single time isn't going anywhere near a model. Agents are for the fuzzy edges. Knowing which side a requirement falls on is the actual job now.

Anyone else seeing their week shift like this?

Related: Copilot in Dynamics 365 — what it actually does

Thanks for reading this article. Hope this Article will help you. Cheers!!!

#Dynamics365 #PowerPlatform #MicrosoftCopilot #DynamicsCRM #CopilotStudio #Dataverse #AIDeveloper #DynamicsAIEngineer #HireAIEngineer #AIEngineer #D365Consultant #CRMDeveloper #AIAgents #MSDyn365