Dataverse and Work IQ: The New Career Edge for D365 Pros

If you only caught the headlines from the Power Platform Community Conference in Las Vegas last week (25 to 29 October), you probably saw the word "agents" a few hundred times and moved on. I'd slow down on one announcement in particular, because I think it quietly changes what a good Dynamics 365 consultant looks like over the next two years.

Microsoft put business applications in Work IQ into public preview, with Dataverse sitting underneath it. In plain English, Copilot and agents can now be taught how your business works, not just where your emails and files are. And the people best placed to do that teaching are the ones who already understand Dataverse tables, relationships, security roles and business rules. That's a lot of you.

What did Microsoft actually announce?

The detail is in James Oleinik's post on the Power Platform blog (23 October). The pitch comes down to three ideas:

• Model your business once. A shared semantic model gives every agent the same understanding of your data, how records relate and what your terms mean, so you don't rebuild that context agent by agent.
• Turn your playbook into business skills. Capture how the organisation works, such as which criteria matter and when approval is required, as reusable skills any agent can follow.
• Act with governance built in. Through Agent 365, agents move from suggestions to governed actions that update systems of record within each user's permissions.

Alongside that, Microsoft listed a batch of new public preview features:

• Business Skills in the Power Apps maker portal now has an agentic experience to help build and edit skills, with version history and simpler ways to secure them.
• The Work IQ MCP Server in Copilot Studio can understand business context.
• A Business Apps plugin in Cowork gives business context and governed actions across existing Dynamics 365 and Power Apps applications.
• The Dataverse Ask API lets you define semantic models for specific scenarios and ask questions in natural language, available as a Web API and through the Dataverse connector.
• Wider extensibility, including a Dataverse plugin in Cowork, Custom API support in the Dataverse MCP Server, and a Microsoft Dataverse node in n8n.

MCP, if you haven't bumped into it yet, is the Model Context Protocol: a standard way for AI tools to discover and use another system's actions. It's the plumbing that lets an agent in one place do real work in another.

Why Custom APIs in the MCP server matter more than they look

The announcement that got me most excited was the least flashy. On 26 October, Kent Weare wrote up Custom API support in the Dataverse MCP Server, and it's worth reading in full if you build on Dataverse.

His example is a support rep asking Copilot to create a high-priority case for a customer whose shipment arrived damaged, add a note and book a follow-up for Friday. Underneath, that's three writes: a case, a note and a task. Let an agent do them as three separate calls and you inherit every problem of non-atomic work. The case gets created, the task fails, and nobody notices until the customer rings back angrier.

The fix is to wrap the whole thing in a Custom API backed by a plug-in, so it runs as one Dataverse transaction. If any step fails, everything rolls back. The agent finds it with a search tool, reads its contract with describe, and runs it with invoke_api. The MCP server builds all of that from the metadata you already created when you registered the API. Microsoft's own search tool instructions even tell the model to prefer an existing Custom API over doing the work itself.

One caveat from the same post: classic Custom Actions are not currently supported in the Dataverse MCP Server. If a client's business logic is still sitting in old actions, that's a migration conversation waiting to happen.

Here's why this matters for your career. The quality of the agent's work now depends heavily on how well someone designed the operation underneath it. Weare puts it bluntly: every name and description in that contract is the model's only source of truth for how to call your API. Clear names produce correct calls. Vague ones produce guesses. That is solution architecture, documentation and good old-fashioned requirements gathering, all of which D365 people already do for a living.

This fits a bigger pattern from October

PPCC didn't happen in isolation. Look at what else landed this month:

• On 8 October Microsoft made 30 pre-built CRM skills generally available in Copilot Cowork, working with more than 180 generally available tools across Sales, Customer Service and Customer Insights.
• On 29 October the Dynamics 365 CX MCP Server for Sales went generally available with 59 governed tools covering opportunities, leads, accounts, activities, pricing, quotes and orders, with existing Dataverse roles and permissions still controlling access.
• Microsoft's message centre lists the Business Central agent design experience with a general availability date of October 2026, letting consultants, product owners and power users prototype custom agents in a sandbox using natural language.

Put those side by side and the direction is obvious. Dynamics 365 is becoming the system of record and the system of action, while more and more of the clicking happens somewhere else: in Copilot, in Cowork, in coding tools, in whatever agent the customer has chosen. The screens matter less. The data model, the rules and the permissions matter a lot more.

I find that genuinely exciting. For twenty years a lot of D365 project time has gone into forms, views and training people where to click. If agents take on a chunk of that, the work moves up a level, to designing how the business should run and making sure the machines follow it properly.

Who wins from this?

I'd put money on four groups having a very good 2027.

Functional consultants who can write things down properly

Business skills are, at heart, your playbook written in plain language: when to approve, what to check, who signs off. If you've ever written a solid functional design document, you already have the core skill. The new bit is writing it so an agent can follow it, then testing whether it actually does.

Dataverse and Power Platform developers

Custom APIs, plug-ins, security roles and clean schema design have just become agent infrastructure. Developers who can turn a fuzzy business process into a well-named, transactional, documented operation will be in demand. Microsoft even ran a PPCC session on coding agents taking a business requirement all the way to a pull request on Dataverse, so expect AI-assisted development to be part of the job, not a threat to it.

Solution architects with a governance head

Agent 365, permissions and data estate governance featured heavily at PPCC. Customers will want someone who can answer "what is this agent allowed to touch, and how do we know?" before they let anything update their finance or customer data. If you enjoy security models, this is your moment.

Data people who understand business meaning

Semantic models are about agreeing what "active customer" or "late order" really means. Consultants who can sit with a finance director, pin those definitions down and model them once will save a client from building the same confusion into every agent they deploy.

What I'd be cautious about

I'm optimistic, but let's be realistic too. Much of what was announced at PPCC is public preview, and preview features change, get renamed or arrive in your region later than you'd like. Don't promise a client production timelines built on preview features without checking the current status on Microsoft Learn first.

There's also a risk of agent sprawl. If every department builds its own agents with its own idea of what a customer is, you get the same mess we had with spreadsheets, only faster. The "model your business once" idea is the answer, and someone has to own it. That someone could be you.

And for hiring managers, a word of warning. Job titles haven't caught up yet. You won't see many roles called "business skills designer" for a while. Look for the skills underneath: Dataverse depth, Custom API experience, strong documentation and governance thinking.

Practical steps you can take this month

You don't need a client project to get started. Here's what I'd do:

• Spin up a Power Platform developer environment and build one Custom API that does a real multi-step job, like creating a case with a note and a follow-up task. Then connect a Copilot or MCP-compatible client and watch it find and call your API.
• Read Microsoft's guide to creating and using Custom APIs if you haven't built one before.
• Take a process you know well and rewrite it as a business skill: the criteria, the approvals, the exceptions. Keep it plain and specific, then test whether an agent follows it.
• Audit an existing solution for old Custom Actions and work out what moving them to Custom APIs would involve. That's a tidy, sellable piece of work for a partner.
• Try the Dataverse Ask API on a small semantic model and see how it handles questions your users actually ask.
• Add a short line to your CV and LinkedIn about agent-ready Dataverse design once you've built something real. Show the project, not just the buzzword.

If you're an employer or partner, run a quick skills check across your team. Who already understands Dataverse security deeply? Who writes the best documentation? Those people are your agent team in waiting, and it's far cheaper to grow them than to hire for a job title that doesn't exist yet.

What does this mean for pay and hiring?

I won't invent numbers. It's too early to see salary data for these specific skills. But the pattern from earlier waves is clear enough: when Power Platform skills went from nice-to-have to expected, the consultants who moved early had more choice of roles. Keep an eye on our D365 salary data as listings start to mention MCP, Custom APIs and Copilot Studio, and check what employers are asking for on the jobs board.

What to do next

• Browse current Dynamics 365 jobs and note how many mention Dataverse, Copilot Studio or agents.
• Compare your rate or salary with our salary pages.
• If you're a consultant with these skills, make sure you're listed in the consultant directory so employers can find you.
• Hiring? Post a role through our employer page and describe the skills, not just the title.
• Exploring tools that sit alongside Dynamics 365? Look through the products and vendors listings.

Pick one item from the practical list above and do it this week. A working Custom API that an agent can call will teach you more than another week of reading about it.