Copilot 7 min read

Copilot Code: I Built a SharePoint CRM and Tested It Like a Real User

Copilot Code planned the SharePoint back end, built a working CRM on top for 5,415 credits, then fixed the gaps I found when I used it like a salesperson would. It's still in preview and not published.

Key takeaways

  • Copilot Code is the Code tab in Microsoft 365 Copilot, next to Chat and Cowork. It builds apps from a plain-language description and is rolling out to Frontier users from late October 2026.
  • In plan mode it proposed the whole SharePoint back end before building: 13 lists, 3 document libraries, how the records relate and an implementation order.
  • The first build of my HubSpot-style CRM used 5,415 Copilot Credits, about US$54 at the US$0.01 pay-as-you-go rate.
  • Testing it the way a salesperson would turned up gaps quickly. I asked for two fixes in the chat and both came back working.
  • Verdict: a strong first pass for an internal app on SharePoint, as long as someone reads the plan, tests it properly and decides on approvals and sharing before it's published.

Copilot Code can plan and build a working business app on SharePoint from a plain-language description. I asked it for a HubSpot-style CRM, and it designed the lists and libraries, built the app on top and fixed the gaps I found in testing, for 5,415 credits on the first build. It’s a strong first pass, but someone who knows the process still needs to read the plan and use the app properly before anyone else sees it.

Copilot Code is the Code tab in Microsoft 365 Copilot, next to Chat and Cowork, and it’s rolling out to Frontier users from late October 2026 (MC1519871). It needs a Microsoft 365 Copilot licence and usage-based billing, with a spending policy your admin sets up. Microsoft’s guide to using Copilot Code covers the controls.

What did Copilot Code plan before it built anything?

I started with a blank team site and put Copilot Code in plan mode, so it would propose the design before touching anything. Literally two minutes later it came back with an information architecture for a SharePoint-backed CRM: five core CRM lists, four relationship lists, four configuration and history lists, and three document libraries, plus how the records relate and the order to build them in. The plan also covered Outlook capture, reminders, imports and reporting.

I approved it, moved the Outlook integration to phase two and told it to build. The model picker offered Claude, GPT and Fable models, and I used GPT-6 Astra.

What did the first build look like?

Copilot Code created the 13 lists in the site, connected the app to them and gave me a preview with an overview, contacts, companies, deals, activities, tasks, documents, playbooks and a settings page. Documents and playbooks are backed by SharePoint document libraries.

The basics were there on the first pass. Owner fields used a people picker, the company form validated before saving, and deals had board and table views with search, filters and saved views. Each deal opened into a record page where I could add notes and tasks, log a meeting and link documents from the libraries. It also added parent companies, so one company can sit under another, without me even asking for it.

The /cost command showed 5,415 credits for the build. At the US$0.01 pay-as-you-go rate that’s about US$54, which I rounded to $55 in the video.

What broke when I used it like a real user?

For Part 2 I sat down with the app, nothing scripted, and did what a salesperson would: added a contact, linked it to a company, created a deal, logged a call and uploaded some documents. All the data was made up.

Part 2: testing the CRM like a real user and asking Copilot Code for fixes

It didn’t take long to find things I’d change. The contact form asked for a first name, a surname and the full name, which is one field too many. I couldn’t link a call to a contact or a company, even though tasks could be linked. And I wanted to drag deals between stages instead of editing each one.

I asked for the drag and drop and the activity linking in the chat and kept testing while it worked. After the app refreshed, still in preview, deal cards dragged between stages with a grip handle, and a new activity could be linked to a contact or a company with filtering on both. The name fields didn’t get changed in that session.

The documents worked best. When I set metadata on a file in the app (status, document owner, review date), the same values were on the file in the SharePoint library, and the file showed up on the company record it was tagged to.

How much did the side requests cost?

While it was making the changes, I asked for a retro Space Invaders game in the same workspace, just for a bit of fun. It built a playable one for 267 credits. A Frogger game I’d made earlier came in at 374. I didn’t check the cost of the CRM change round itself.

Read the plan like a solution design before you approve it

The plan is where your experience counts. I read it the way I’d read a solution design from a consultant: which lists exist, how they relate, what gets built first and what can wait. Moving Outlook to phase two took one line in the chat before the build. After the build, the same change means reworking lists that already hold data. If you’ve already got requirements or an architecture document, you can upload it and have Copilot Code build from that.

Keep the data in SharePoint. Contacts, deals, activities and documents sit in lists and libraries in your tenant, under the permissions you already manage, and the metadata the app writes is the same metadata your library views use. Sharing a published app doesn’t share the data behind it: people only see what they already have access to in the connected sources. So the site’s permissions decide who sees which customer, and they need sorting before you share. If you’re new to designing columns this way, why columns beat folders covers it.

Be careful with “always allow”. It asked before creating lists and before using Microsoft Graph, and I clicked always allow to keep the recording moving. Living on the edge, a bit risky. That setting stays on across existing and new sessions and workspaces until you turn it off, so on a production tenant I’d leave the prompts on until I trusted what it was doing.

Test it before anyone else does. In my test the first build looked finished, and one unscripted session turned up three things I’d want fixed before a sales team used it. Building doesn’t publish anything; publishing is a separate step you ask for, so there’s room to test and fix in preview first. Then run a small pilot and check credit use in the Microsoft 365 admin center before you estimate a monthly cost.

For comparison, I built a similar CRM in September with Copilot Cowork’s App skill. There’s also my earlier test of the App Builder agent, which Microsoft is retiring.

Frequently asked questions

Who can use Copilot Code? Frontier program users with a Microsoft 365 Copilot licence and a spending policy for usage-based billing. Admins manage it under Copilot, Cost management in the Microsoft 365 admin center. Cloud coding is on by default for eligible users, local coding on PC is off by default, and connecting Code to GitHub needs an admin to turn it on.

Can I see the code Copilot Code writes? Yes. In my session the workspace showed the files Copilot Code had generated, and I could open them to read the code. Code view lets you switch to the raw code for any project, and editing the files there is limited to local projects.

What happens when someone opens a published app that uses a SharePoint list? They see only the records they already have permission to see in that list. The first time they open the app, they may be asked to approve the connection to the list.

Get these in your inbox. One email a week.

Practical thinking on organising your information and getting real work out of AI. Subscribers get the free SharePoint Skill course to start.