Picture a standard Dataverse build. Someone designs the tables first. Then come relationships, security, and test data. The app itself starts last. Each step lives in a different tool. Each handoff costs days.
On October 28, 2026, Microsoft’s Dataverse team put a faster build on screen. One prompt asked for an event registration app. Copilot Cowork returned two linked tables, four sample events, and a published app.
The Dataverse plugin in Copilot Cowork did the building. The result was a Dataverse app in Copilot, running under your security roles. Nothing changed until a person clicked Approve. Speed alone will not win over a leadership team. Before anyone approves a pilot, three things need answers:
- Who approves what the agent builds?
- Where does the data live?
- What does IT still own?
This guide answers all three in plain terms.
What the Dataverse Plugin in Copilot Cowork Builds from One Prompt
Microsoft’s demo asked for an event registration app. The prompt set clear rules:
- Capacity, start time, end time, venue and date are required for events.
- Registrations reuse contacts already stored in Dataverse.
- Each person registers once per event.
- Full events send new sign-ups to a waitlist.
The plugin gives Cowork a connection to your environment. It also loads skills for data modeling, records, business logic, security, and solutions. Cowork then plans the work like an experienced Dataverse maker.
Here is what it built:
- An Event table and an Event Registration table
- Relationships, added in separate and reviewable steps
- Four sample events, with one filled to capacity
- A sample data flag on every seeded row, so cleanup stays easy
Why Reusing Existing Tables Matters
Cowork linked registrations to the existing Contact table. It did not invent a new list of people. That keeps the app on data your organization already trusts. Duplicate records stay out. Reports stay clean. Both finance and operations team use the same numbers.
How a Dataverse App in Copilot Gets Published
Once the tables exist, Cowork switches to its native app-building flow. It creates the app and connects it to Event and Event Registration. A theme goes on too. Then it writes the data layer and screens. Before publishing, it runs the checks a careful engineer would run:
- Type checking
- Linting
- A full build
- A visual review of the layout
The published app runs in Microsoft Copilot Managed Runtime, which is in preview. It uses Microsoft Entra sign-in. Your tenant’s governance policies apply the moment the app is created. IT admins can see it in the Microsoft 365 admin center. They can monitor and manage it there too.
| Stage | What Cowork does | What stays with you |
|---|---|---|
| Data model | Creates tables and links to Contact | Approval of each change |
| Sample data | Seeds four events and flags the rows | Deleting test records |
| App build | Binds tables, writes screens, runs checks | Review of the result |
| Publish | Deploys to Managed Runtime | Tenant policies and admin oversight |
What Does the Finished App Look Like?
The published app gives teams two useful views:
- Organizer view: Upcoming events are displayed showing their date, place, and level of occupancy. Who has signed their name for each event is included.
- Check-in view: Built for attendance. Staff can check people in or cancel a registration.
Both views work directly with Dataverse records. Updates remain connected to the same business data.
Governance Is Part of the Flow
Agents that write to a system of record must earn trust. The Dataverse plugin in Copilot builds that trust in three ways.
- Identity: The connection signs in as you. Cowork sees only what your security roles allow. Dataverse checks every request on the server.
- Approval: All changes are available for a review prior to approval in the form of an approval card. Nothing happens behind your back.
- Location: Work happens in your own environment. The tables are ordinary Dataverse tables, ready for your solutions and lifecycle practices.
One moment in the demo shows this well. Cowork noticed the default environment had no Dataverse database. It stopped and asked which environment to use. Then it built the app next to its data.
More agents means more risk to manage. Gartner’s forecast is blunt. More than 40% of agentic AI projects will be discontinued by the end of 2027. The causes: rising costs; uncertainty on business value and poor risk management.
Adoption is climbing fast too. Gartner also expects agentic AI in 33% of enterprise software applications by 2028. In 2024, that share was below 1%.
Your risk team will want something concrete to inspect. Role-based access and approval cards give them exactly that.
What an Approval Card Looks Like
In one example, a card asked to update a Dataverse table. It wanted to add an Event lookup to Event Registration. The maker saw two buttons: Cancel and Approve.
That detail matters. Reviewers see every table and column change before it lands. If something looks off, your team can pause, ask, or say no.
Review each card for:
- Which table is changing
- Which column or relationship is being added
- Whether it fits your naming standards
What Each Leadership Priority Should Ask
| Priority | Question to Ask | What the demo shows |
|---|---|---|
| Cost and ROI | How fast does a pilot reach a working app? | One prompt reached a published app |
| Risk and security | Who does the agent act as? | It signs in as you, and your roles apply |
| Data quality | Does the app copy our data? | It reuses Contact and adds no separate database |
| Architecture | Where does the app run? | In your environment, on Managed Runtime (preview) |
| Operations | Can teams extend it later? | Records are ready for Power Automate and Copilot Studio agents |
Each answer points to the same idea. The agent works inside your existing controls. Your teams keep the decisions that matter.
Business Rules That Hold Up in Testing
In the demo, the team added a Pumpkin Carving Showdown with three seats. They registered three contacts straight from Dataverse. The event filled up. A fourth person landed on the waitlist automatically. That matched the original prompt.
Opening the tables in Power Apps confirmed it. Every action in the app wrote to Dataverse. There is no separate database. There is no copy to keep in sync. The same records are ready for Power Automate, Copilot Studio agents, and reporting.
The waitlist test proves a useful point. Rules typed in plain language became working logic. The prompt itself acted as the spec. Business owners can check the result themselves. They use real contacts and a full event. The tables stay ordinary Dataverse tables, so your usual review applies. That shortens the loop between an idea and a test.
What to Check Before You Start a Pilot
Early access comes with conditions. Plan around them.
- Building apps in Cowork currently requires enrollment in the Frontier program.
- Microsoft Copilot Managed Runtime is still in preview.
- Try it first in a Power Apps Developer Plan environment, away from production data.
- Pick a low-risk internal job for round one, like a simple intake form.
- Name your approvers before the first prompt runs.
- Agree on security roles and solution structure up front.
Treat your first Dataverse app in Copilot as a controlled experiment. Measure build time, review effort, and data quality.
Dataverse also reaches other tools, including GitHub Copilot, Cursor, Gemini CLI, and n8n. Microsoft’s aim is one trusted data layer with the same guardrails everywhere.
Connecting the Dataverse Plugin
Getting started takes only a few steps:
- Open Customize in Copilot Cowork.
- Find the Microsoft Dataverse plugin and select Connect.
- Enter your Dataverse environment URL.
- Describe the app you want to build.
- Review the proposed changes and approve them individually.
Cowork builds only what you approve. Your team stays in the loop from start to finish. Your team stays involved throughout the build.
Plan Your First Governed Pilot
Going from idea to working app used to mean juggling several tools. The Dataverse plugin trims that to one prompt and a round of approvals. Your team keeps its say over roles, environments, and sign-offs.
DynaSUM, a Microsoft Solutions Partner, helps with everything around the build. Our Security & Governance advisory work sets the guardrails first. Our AI & Agent Engineering team builds on top of them. Do you require a second opinion before your first pilot? The expert DynaSUM team is always ready to assist you.
FAQs
1. What does the Dataverse plugin in Copilot do?
It connects Copilot Cowork to your Dataverse environment. It adds skills for tables, records, business logic, security, and solutions. Cowork uses them to plan and build. You approve each step.
2. Does a Dataverse app in Copilot follow our security roles?
Yes. The connection signs in as you. Cowork can only see and change what your roles allow. Dataverse checks every request on the server. The plugin cannot bypass those permissions.
3. What do we need to try the Dataverse plugin in Copilot Cowork?
Start with a Dataverse environment. A Power Apps Developer Plan environment works well for tests. Building apps in Cowork currently requires Frontier program enrollment. Published apps run in Microsoft Copilot Managed Runtime, which is in preview.
