Ever wish Business Central actually did the boring work for you? Like reconciling payments or drafting product text, instead of burying you in extra clicks and late-night Excel misery? That’s the promise of Copilot. And before you ask—yes, it’s built into Business Central online at no extra cost. Just don’t expect it to run on your on-prem install. Here’s the catch: most admins never look past the canned demos. Today we’ll strip it down and show you how to make Copilot work for *your* business. By the end, you’ll walk away with a survival checklist you can pressure-test in a sandbox. And it all starts with the hidden menu Microsoft barely talks about.The Secret Menu of CopilotCopilot’s real power isn’t in the flashy buttons you see on a customer card. The real trick is what Microsoft left sitting underneath. You’ll find those extension points inside the `System.AI` namespace — look for the Copilot Capability codeunit and related enums. That’s where the actual hooks for developers live. These aren’t random artifacts in the codebase. They’re built so you can define and register your own AI-powered features instead of waiting for Microsoft to sprinkle out a new demo every quarter. The menu most people interact with is just the surface. Type invoice data, get a neat summary, maybe draft a product description — fine. But those are demo scenarios to show “look, it works!” In reality, Business Central’s guts contain objects like Copilot Capability and Copilot Availability. In plain English: a Capability is the skill set you’re creating for Copilot. Availability tells the system when and where that skill should show up for end users. Together, that’s not just a menu of canned AI widgets — it’s a framework for making Copilot specific to your company. Here’s the kicker: most admins assume Copilot is fully locked down, like a shiny black box. They use what’s there, shrug, and move on. They never go looking for the extra controls. But at the developer level, you’ve got levers exposed. And yes, there’s a way for admins to actually see the results of what developers register. Head into the “Copilot & agent capabilities” page inside Business Central. Every capability you register shows up there. Admins can toggle them off one by one if something misbehaves. That connection — devs define it in AL, admins manage it in the UI — is the bridge that makes this more than just theory. Think of it less like a locked Apple device and more like a console with hidden debug commands. If all you ever do is click the main Copilot button, you’re leaving horsepower on the table. It’s like driving a Tesla and only ever inching forward in traffic. The “Ludicrous Mode” switch exists, but until you flip it, you’re just idling. Same thing here: the namespace objects are already in your tenant, but if you don’t know where to look, you’ll never use them. So what kind of horsepower are we talking about? The AI module inside Business Central gives you text completions, chat-like completions for workflow scenarios, and embeddings for semantic search. That means you can build a capability that, for example, drafts purchase orders based on your company’s patterns instead of Microsoft’s assumptions. It also means you can create assistants that talk in your company’s voice, not some sterilized HR memo. Quick note before anyone gets ideas: the preview “Chat with Copilot” feature you might have seen in Business Central isn’t extensible through this module. That chat is on its own path. What you *do* extend happens through the Capability model described here. Microsoft did a poor job of surfacing this in their marketing. Yes, it’s in the docs, but buried in a dry technical section few admins scroll through. But once you know these objects exist, the picture changes. Every finance quirk, every weird custom field, every messy approval workflow — all of it can be addressed with your own Copilot capability. Instead of waiting for Redmond to toss something down from on high, you can tailor the assistant directly to your environment. Of course, nothing this powerful comes without warning labels. These are sharp tools. Registering capabilities wrong can create conflicts, especially when Microsoft pushes updates. Do it badly, and suddenly the sandbox breaks, or worse, you block users in production. That’s why the Copilot & agent capabilities page matters: not only does it give admins visibility, it gives you a quick kill switch if your custom brain starts misbehaving. So the payoff here is simple: yes, there’s a secret menu under Copilot, yes, it’s in every tenant already, and yes, it turns Copilot from a demo toy into something useful. But knowing it exists is only step one. The real trick is registering those capabilities safely so you add firepower without burning your environment down — and that’s where we go next.Registering Without Burning Down Your TenantRegistering a Copilot capability isn’t some vague wizard trick. In plain AL terms, it means you create an `enumextension` for the `Copilot Capability` enum and then use an `Install` or `Upgrade` codeunit that calls `CopilotCapability.RegisterCapability`. That’s the handshake where you tell Business Central: “Here’s a new AI feature, treat it as part of the system.” Without that call, your extension might compile, but Copilot won’t even know the feature exists. Think of it as submitting HR paperwork: no record in the org chart, no desk, no email, no employee. Once you’ve got the basic definition in place, the next detail is scope and naming. Every capability you register lives in the same ecosystem Microsoft updates constantly. If you recycle a generic name or reserve a sloppy ID, you’re basically begging for a collision. Say you call it “Sales Helper” and tag it with a common enum value—then Microsoft ships a future update with a built-in capability in the same space. Suddenly the system doesn’t know which one to show, and your code is arguing with Redmond at runtime. The mitigation is boring but essential: pick unique names, assign your own enum values that don’t overlap with the common ranges, and version the whole extension deliberately. Add version numbers so you can track whether sandbox is on 1.2 while production’s still sitting at 1.0. And if something changes with the platform, your upgrade codeunits are the tool to carry the capability forward safely. Without those, you’re duct-taping new wiring into an old breaker box and hoping nothing bursts into flames. Now here’s where too many developers get casual. They throw the extension straight into production because “it’s just a capability.” That’s when your helpdesk lights up. The right path is simple: sandbox-only first. Break it, refactor, test it again, and only when it behaves do you move to prod. That controlled rollout reduces surprises. And this isn’t just about compiling code—it’s about governance. The Copilot & Agent capabilities page in Business Central doubles as your sanity check. If your capability doesn’t appear there after registration, you didn’t register it properly. That page reflects the system’s truth. Only after you’ve validated it there should you hand it off for admin review. And speaking of admins, flipping Copilot capabilities on or off, as well as configuring data movement, is something only admins with SUPER permissions or a Business Central admin role can do. Plan for that governance step ahead of time. A quick pro tip: when you register, use the optional `LearnMoreUrlTxt` parameter. That link shows up right there in the Copilot & Agent capabilities admin page. It’s not just a nice touch—it’s documentation baked in. Instead of making admins chase down a wiki link or bother you in Teams, they can click straight into the description of what the capability does and how to use it. Think of it as writing instructions on the actual light switch so the next person doesn’t flip the wrong one. Here’s a best-practice checklist that trims down the risks: 1) run everything in a sandbox before production, 2) pick unique enum values and avoid common ranges, 3) always use Install/Upgrade codeunits for clean paths forward, 4) attach that LearnMoreUrl so admins aren’t guessing later. Follow those four, and you’ll keep your tenant stable. Ignore them, and you’ll be restoring databases at three in the morning. The parking space metaphor still applies. Registering a capability is like officially reserving a spot for your new car. Fill out the right paperwork, it’s yours and everyone’s happy. Skip the process or park in the red zone, and now you’re blocking the fire lane and everyone’s angry. Registration is about carving out safe space for your feature so Business Central and Microsoft’s updates can coexist with it longer term. Bottom line: treat registration like production code, because that’s exactly what it is. Test in sandboxes, keep your scope unique, track your versions, and make your upgrade codeunits airtight. If something weird happens, the Copilot & Agent capabilities page plus your LearnMoreUrl is how admins will find, understand, and if needed, shut down the feature. Done right, registration sets you up for stability. Done sloppy, it sets you up for chaos. Once you’ve got that locked down, you’ll notice the capability itself is functional but generic. It answers, but without character. That’s like hiring someone brilliant who shows up mute at meetings. The next step is teaching your Copilot how to act—because if you don’t, it’ll sound less like a trusted assistant and more like a teenager rolling their eyes at your questions.Metaprompts: Teaching Your AI MannersThat leads us straight into metaprompts—the part where you stop leaving Copilot adrift and start giving it rules of engagement. In Microsoft’s own developer docs, a metaprompt is the “primary system message” that defines the model’s profile, output format, and guardrails. Plain English: it’s the AI’s job description. A one-off user prompt

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.

If this clashes with how you’ve seen it play out, I’m always curious. I use LinkedIn for the back-and-forth.