3.3 Using AI to Create & Edit Dataverse Schema

Microsoft Power Platform Fundamentals PL-900

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 What PL-900 Tests in 2026 1.2 Exam Logistics & Scoring 1.3 The Power Platform Ecosystem

2 Business Value of Microsoft Power Platform (5-10%)

2.1 Business Value of Power Apps & Power Automate 2.2 Business Value of Dataverse & Connectors 2.3 Business Value of Power Pages, Generative AI & Copilot Studio Agents

3 Manage the Environment: Microsoft Dataverse (20-25%)

3.1 Dataverse vs Traditional Databases; Tables, Columns, Relationships 3.2 Forms, Views & Business Logic (Power Fx, Business Rules) 3.3 Using AI to Create & Edit Dataverse Schema

4 Manage the Environment: Administration & Governance (20-25%)

4.1 Environments & Their Purposes 4.2 The Power Platform Security Model (Roles, Business Units, Teams) 4.3 Data Privacy (DLP), Monitoring/Analytics & ALM Pipelines

5 Demonstrate the Capabilities of Power Apps (20-25%)

5.1 Canvas Apps: Use Cases & Capabilities 5.2 Model-Driven Apps, Plan Designer & Code Apps 5.3 Building Apps with AI (Vibe Experience)

6 Demonstrate the Capabilities of Power Automate (20-25%)

6.1 Cloud & Desktop Flows: Types & Use Cases 6.2 Building Flows: Triggers, Actions & AI Assistance 6.3 Automating Microsoft 365 & Document Processes

7 Agents in Microsoft Copilot Studio (20-25%)

7.1 Building Agents: Topics, Knowledge, Tools (MCP, Agent Flows), Publishing 7.2 Managing Agents: Microsoft Agent 365, Monitoring & Evaluations

3.3 Using AI to Create & Edit Dataverse Schema

Key Takeaways Explain This Topic AI

Copilot in the Power Apps maker experience can generate tables, columns, and relationships from a natural-language description of the data

Makers can continue prompting Copilot conversationally to add columns, change data types, or connect tables after the initial schema is created

Copilot favors reusing existing standard tables (such as Contact) rather than generating duplicates when possible

AI-generated schema should be reviewed before publishing to confirm correctness, avoid redundant tables, and verify relationship cardinality

Copilot's schema-creation capability operates within the permissions of the maker who is using it, not beyond them

Last updated: July 2026

Designing a Dataverse schema by hand — creating each table, adding every column, and wiring up every relationship one at a time in the maker portal — is entirely possible, but it is not the only way anymore. Copilot is built into the Power Apps maker experience, and PL-900 expects candidates to know how AI can create and edit Dataverse schema from natural-language descriptions, not just from manual clicks through the interface.

Describe Your Data: Copilot-Assisted App Creation

When starting a new app in Power Apps, a maker can skip the blank-canvas approach and instead describe the app in plain language — for example, "Track office equipment reservations for my team, including who reserved what and when it's due back." Copilot interprets that description and proposes a Dataverse schema to support it: relevant tables (such as Equipment and Reservation), appropriate columns on each table with sensible data types (a Due Date as a date/time column, a Status as a choice column), and the relationships connecting them (a Reservation looking up to an Equipment record and to the person who made it).

Where possible, Copilot favors reusing standard tables already in the environment — for instance, linking a reservation to the existing Contact table rather than generating a duplicate "Person" table — which keeps the schema consistent with tables other apps and Dynamics 365 processes may already depend on. Alongside the proposed schema, Copilot typically generates a working starter app immediately, so the maker sees tables, columns, relationships, and a usable canvas or model-driven app together rather than designing the data model and the app as two separate manual steps.

Editing Schema with Natural-Language Prompts

Schema creation with AI is not limited to the initial prompt. A maker can continue describing changes conversationally, and Copilot updates the schema accordingly:

Natural-Language Request Resulting Schema Change

"Add a Priority column to the Reservation table" A new choice column is created with suggested option values (Low, Medium, High)

"Track which department owns each piece of equipment" A new lookup column (or table) is proposed to model the relationship

"Make the Return Date required" An existing column's requirement level is updated

"Change Notes to allow longer text" An existing column's data type is adjusted (for example, from single line to multiple lines of text)

This conversational editing extends to relationships too — a maker can ask Copilot to connect two existing tables, and it will propose the appropriate lookup column and relationship type (one-to-many or many-to-many) rather than requiring the maker to configure it manually in the table designer.

Why Human Review Still Matters

AI-generated schema is a draft , not a final, automatically correct answer, and PL-900 treats "review before publishing" as part of the expected workflow rather than an optional extra step. A maker should check that:

Copilot did not create a redundant custom table when a standard table (Account, Contact) already covers the need

Suggested column data types and choice values actually match the business scenario

Suggested relationships point in the correct direction and use the correct cardinality (one-to-many vs. many-to-many)

Any proposed changes to existing tables will not break forms, views, or flows that already depend on them

It is also worth remembering that Copilot in the maker experience acts within the permissions of the maker who is using it — the AI does not have privileges beyond the person prompting it, so what it can create or modify is bounded by that maker's existing security role and environment access, not by the AI itself. If a maker lacks permission to create new tables in an environment, describing a schema to Copilot will not bypass that restriction; the same governance controls covered elsewhere in this domain still apply to AI-assisted changes.

Why This Matters for Makers

Using AI to create and edit Dataverse schema does not replace understanding tables, columns, and relationships — it changes how quickly a correctly modeled schema comes together. A maker who understands the concepts from the earlier sections in this chapter is far better equipped to evaluate whether an AI-generated table, column, or relationship is actually right for their scenario, rather than accepting a suggestion without knowing what it means. On the exam, expect questions that test whether you know AI-assisted schema creation exists as a capability in the maker experience, what kind of natural-language requests it can act on (creating and editing tables, columns, and relationships), and that a maker's review is still part of the process.

Key Takeaways

Copilot in the Power Apps maker experience can generate tables, columns, and relationships from a natural-language description of the data

Makers can continue prompting Copilot conversationally to add columns, change data types, or connect tables after the initial schema is created

Copilot favors reusing existing standard tables (such as Contact) rather than generating duplicates when possible

AI-generated schema should be reviewed before publishing to confirm correctness, avoid redundant tables, and verify relationship cardinality

Copilot's schema-creation capability operates within the permissions of the maker who is using it, not beyond them