# Microsoft Dataverse: The Data Foundation

> Chapter 3 of the Courseiva PL-900 curriculum — https://courseiva.com/learn/pl-900/power-platform-dataverse

**Official objective:** 2.1 — Describe Microsoft Dataverse

## Introduction

Exam objective 2.1 asks you to describe Microsoft Dataverse, which is the data foundation of the entire Power Platform. If you have ever tried to share a spreadsheet with a colleague only to end up with three different versions and no one knowing which one is correct, you have felt the exact problem Dataverse is designed to solve. For your PL-900 exam, understanding Dataverse is non-negotiable because it is the engine behind Power Apps, Power Automate, and Power Virtual Agents — and questions about it appear in every exam domain.

## The Town Architect Analogy

The Town Architect is the person responsible for designing the master blueprint of a new housing development. Before a single brick is laid, this architect walks the land, marks where houses, roads, parks, and shops will go, and writes a detailed rulebook. This rulebook says, “Every house must have a concrete foundation, every road must be wide enough for a fire truck, and every park must have a bench every 50 metres.” The rulebook doesn’t build anything itself, but it makes sure that when builders arrive, they all work from the same plan. If a builder puts a door where a window should be, the rulebook catches the mistake before the wall goes up. The town grows in an orderly, predictable way because the blueprint defines the structure in advance.

The architect never carries bricks or pours concrete. The architect’s job is to define the rules, the shapes, and the relationships between every piece of the town. When a new builder shows up and asks, “Where should I dig the foundation?”, the architect points to the blueprint. No confusion, no wasted work, no houses that block the sun from the park.

Now take that blueprint, make it digital, and give it to a thousand builders who can all look at it at the same time from anywhere in the world — that is Microsoft Dataverse. Dataverse is the master blueprint for your business data. It defines what kind of data you can store (like “Customer” or “Order”), what rules that data must follow (like “an order must belong to a customer”), and how the data pieces fit together. It stores the data securely in the cloud, so every app and every user sees the same version of the truth.

## Core explanation

Microsoft Dataverse is a cloud-based data storage and management service that lives inside the Microsoft Power Platform. Think of it as a supercharged, intelligent database designed specifically for business apps. Unlike a simple Excel sheet or a flat file, Dataverse enforces rules about what data can be entered, how different pieces of data relate to each other, and who can see what.

Let’s start with the basics. **Data** is just information — names, dates, prices, product codes. **Storage** is where that information lives — a hard drive, a USB stick, or, in this case, Microsoft’s cloud servers. A **database** is an organised collection of data, like a digital filing cabinet. Dataverse is a particular type of database called a **relational database**, which means it specialises in connecting different kinds of information together.

Why does this matter? Before Dataverse, business data was often scattered everywhere. Sales data lived in one spreadsheet, customer support data in another, inventory data in a third. People emailed files, renamed them, saved new versions, and soon nobody knew which spreadsheet was the real one. Dataverse solves this by giving everyone one central, always-up-to-date place for data.

Here are the core components of Dataverse that you need to know for PL-900:

- **Tables**: A table is a container for one type of thing. For example, a “Customer” table holds all customers. A “Product” table holds all products. Each row in a table is a single record (one customer), and each column is a field (Name, Phone Number, Email).
- **Columns**: Columns define what kind of data you can put in each field. Common data types include Text, Number, Date/Time, Currency, and Choice (a drop-down list of options).
- **Relationships**: This is what makes Dataverse powerful. Relationships connect tables to each other. For example, an “Order” table can have a relationship to the “Customer” table, so every order automatically knows which customer it belongs to. The main types are one-to-many (one customer has many orders) and many-to-many (one product can be in many orders, and one order can have many products).
- **Business Rules**: These are simple if-then logic rules that ensure data quality. Example: “If Country is ‘USA’, then State must be provided.” The rule runs automatically every time someone enters or edits data.
- **Security Roles**: These control who can read, write, delete, or share data. A manager might see all sales data; a sales rep might only see their own.
- **Auditing**: Dataverse can track every change made to data — who changed it, what they changed it from and to, and when. This is critical for compliance and accountability.

Dataverse replaces the old way of building apps where developers had to design a custom database from scratch — writing complex code, setting up servers, managing backups, and worrying about security. With Dataverse, all of that is handled by Microsoft. Your job is to define the tables, columns, and rules, and Dataverse does the heavy lifting.

For the Power Platform, Dataverse is the “write once, use everywhere” layer. You build a table in Dataverse, and then any Power App, Power Automate flow, or Power Virtual Agent chatbot can use that same data immediately. No importing, no syncing, no duplicate files.

Dataverse also has **built-in intelligence**. It can run **business logic** automatically — for example, when a new order is created, it can automatically calculate the total price. It also supports **plug-ins** (custom code for advanced scenarios) and **workflows** (automated sequences of actions).

Finally, Dataverse is part of the **Microsoft ecosystem**. It integrates natively with Microsoft 365 (Outlook, Teams, SharePoint) and Dynamics 365 (Microsoft’s business applications). And because it lives in the cloud, it is always available, automatically backed up, and scalable from a handful of records to millions.

## Real-world context

Meet Priya, an IT professional who works for a medium-sized logistics company. The company has used spreadsheets for years to track shipments, but they are drowning in errors. Different offices have different versions of the same spreadsheet. One office calls the column “Delivery Date”, another calls it “Ship Date”, and a third uses “Date Delivered”. When Priya tries to create a dashboard showing on-time delivery rates, she spends most of her time cleaning up data.

Priya decides to use Microsoft Dataverse to fix this mess. Here is exactly what she does, step by step:

1. **She opens the Power Apps maker portal** and navigates to the Dataverse area. She creates a new environment called “Logistics-Prod” to keep this data separate from testing work.
2. **She creates a “Shipment” table**. She defines columns: ShipmentID (auto-number), CustomerName (text), Origin (text), Destination (text), DeliveryDate (date), Status (choice: Pending, In Transit, Delivered, Failed). She sets the Status column to default to “Pending” so no record is ever created without a status.
3. **She creates a “Customer” table** with columns for CompanyName, ContactEmail, and Phone. She then creates a relationship between Shipment and Customer: one customer can have many shipments. Now, when entering a new shipment, Priya can just pick the customer from a drop-down instead of typing the name each time — this eliminates typos.
4. **She sets up business rules**. One rule says: “If Status is ‘Delivered’, then DeliveryDate must be filled in.” Another says: “If Status is ‘Pending’, the DeliveryDate cannot be in the past.” These rules run automatically, so bad data never enters the system.
5. **She configures security roles**. The warehouse team gets “Read” and “Update” access to shipments but cannot delete records. Managers get “Full Access”. Customer service reps get read-only access.
6. **She builds a Power App** (a custom app with buttons and forms) that connects to this Dataverse. Now her colleagues in three different cities open the same app, see the same live data, and enter new shipments following the same rules. No more version conflicts.
7. **She creates a Power Automate flow** that triggers whenever a shipment status changes to “Delivered”: it automatically sends an email to the customer with a confirmation link.

What did Priya achieve? She eliminated data chaos without writing any database code. She set up a professional-grade data foundation in a few hours. If a new office joins next year, she just gives them access to the environment, and they are immediately working on the same data. For an IT professional, this means less time firefighting and more time building value.

## Exam focus

The PL-900 exam will test your understanding of Dataverse at a conceptual level. You will not be asked to build a table or write a query. Instead, you need to recognise what Dataverse is, what it replaces, and how it connects to other Power Platform components.

**Concepts that appear frequently:**
- The primary role of Dataverse as the **centralised data store** for Power Apps, Power Automate, and Power Virtual Agents.
- **Tables, columns, and relationships** — you need to know what they are and how they map to real-world scenarios. Expect questions that say, “You have a list of customers and a list of orders. Which Dataverse feature links them together?” The answer is “a relationship”.
- **Business rules** — they are described as “simple logic that runs on a table”. Traps: a business rule is NOT a Power Automate flow. Business rules are designed for basic validation, not complex automation.
- **Security roles** — Dataverse has its own security model separate from Microsoft Entra ID. Questions will test whether you know that table-level permissions (Read, Write, Delete) are set inside Dataverse, not in Microsoft Entra ID.
- **Standard vs. custom tables** — Dataverse comes with hundreds of pre-built “standard” tables (like Account, Contact, Activity). You can also create your own “custom” tables. Exam questions like to ask: “Which table is provided by default?” The answer is often “Account” or “Contact”.
- **Environment** — a container for Dataverse data, apps, and flows. Each environment has its own security, backups, and region. Questions might ask: “Where do you create a Dataverse database?” Answer: inside an environment.

**Common traps:**
- Confusing Dataverse with SharePoint lists or Excel. These are NOT the same. Dataverse enforces relationships and business rules; SharePoint lists do not.
- Thinking that Dataverse is the same as a SQL Server database. While both are relational, Dataverse is fully managed and includes built-in security, auditing, and integration. For the exam, treat Dataverse as a **business-ready database** that requires zero server management.
- Mixing up “business rules” with “Power Automate flows”. A business rule is a simple declarative rule that runs on a single table. A flow can orchestrate complex multi-step processes across many tables and services.
- Believing that Dataverse requires coding. It does not — you can build everything through the graphical interface in the Power Apps maker portal.

**Question styles:**
- Multiple-choice: “Which component of the Microsoft Power Platform provides a secure, scalable data platform?” Answer: Microsoft Dataverse.
- Drag-and-drop: Match Dataverse terms (Table, Column, Relationship) to their descriptions.
- Select-all-that-apply: “Which of the following are benefits of using Dataverse?” (Central storage, security roles, relationships, etc.)
- True/False: “Dataverse can only be used by Power Apps.” False — it also works with Power Automate, Power Virtual Agents, and external apps via APIs.

## Step by step

1. **Create an Environment** — Go to the Power Platform admin centre and create a new environment. An environment is a container that isolates your Dataverse data, apps, and flows. It is like setting up a separate workshop for a specific project. Without an environment, you cannot have a Dataverse database.
2. **Provision the Dataverse Database** — Inside that environment, click to provision a Dataverse database. This tells Microsoft to allocate cloud storage and set up the database engine. You choose the region (where your data is stored geographically) and the currency/language settings. This step takes a minute or two and turns the empty environment into a live database.
3. **Define Tables and Columns** — In the Power Apps maker portal, navigate to the Dataverse section and create new tables (like 'Customer', 'Order', 'Product'). For each table, add columns with appropriate data types (text, number, date, choice). This defines the structure of your data — what you are storing and what format it must be in.
4. **Create Relationships Between Tables** — Use the relationship designer to connect tables. For example, create a one-to-many relationship from 'Customer' to 'Order'. After this step, when you enter a new order, you can select which customer it belongs to from a drop-down. The database now ensures that every order is linked to a real customer, preventing stray data.
5. **Set Up Business Rules and Security** — Add business rules to enforce data quality (e.g., 'If country is USA, state is required'). Then configure security roles — assign permissions so that only authorised users can create, read, update, or delete records. This step makes your database reliable and secure before anyone starts using it.
6. **Connect Apps and Flows** — Finally, build a Power App or a Power Automate flow that points to your Dataverse tables. When you save the app or flow, it is immediately connected to live data. Any changes made through the app update the Dataverse database in real time, and other apps see those changes instantly.

## Comparisons

### Dataverse vs SharePoint List

**Dataverse:**
- Supports multiple related tables (e.g., Customer ↔ Order)
- Enforces business rules and data validation automatically
- Has granular security roles per table and record

**SharePoint List:**
- Is a single flat list — no built-in table relationships
- Validation is limited to column-level settings and Power Automate
- Security is primarily at list-level (view/edit/delete)

### Dataverse Business Rule vs Power Automate Flow

**Dataverse Business Rule:**
- Runs directly on the Dataverse table — no external trigger needed
- Handles simple logic: set field values, show/hide fields, validate data
- Requires no licensing beyond Dataverse access

**Power Automate Flow:**
- Runs in a separate service — can be triggered by hundreds of events
- Handles complex multi-step processes: send emails, call APIs, update multiple tables
- Has separate licensing costs (Per Flow plan) and may require premium connectors

### Dataverse Standard Table vs Dataverse Custom Table

**Dataverse Standard Table:**
- Pre-defined by Microsoft (e.g., Account, Contact, Activity)
- Comes with default columns, relationships, and forms
- Cannot be deleted — only customised or hidden

**Dataverse Custom Table:**
- Created by you from scratch — you define every column and relationship
- Has no pre-built columns or forms — you build everything
- Can be deleted if no longer needed

### Dataverse Environment vs Microsoft Entra ID Tenant

**Dataverse Environment:**
- A container for Dataverse databases, apps, and flows
- Has its own security roles and data policies
- Can be created, deleted, and duplicated independently

**Microsoft Entra ID Tenant:**
- The overarching Azure and Microsoft 365 identity directory
- Manages user accounts, passwords, and group memberships
- Typically one per organisation — contains all environments

## Diagram

_How apps connect to Dataverse, which uses tables, relationships, business rules, and security roles to manage data._

```mermaid
flowchart TD
    A[User] --> B[Power App / Power Automate / Power Virtual Agents]
    B --> C[Dataverse API]
    C --> D[Dataverse Database]
    D --> E[Tables]
    D --> F[Relationships]
    D --> G[Business Rules]
    D --> H[Security Roles]
    E --> I[Columns]
    E --> J[Records]
    D -.-> K[Microsoft Entra ID - Authentication]
```

## Common misconceptions

- **Misconception:** Dataverse is just another name for an Excel spreadsheet in the cloud. **Reality:** Dataverse is a relational database that enforces data types, relationships, business rules, and security. Excel is a flat-file tool with no built-in relationship or rule enforcement. (Many beginners come from a spreadsheet-heavy background and assume cloud storage is just ‘Excel online’. They do not recognise the structural differences until they try to connect two tables.)
- **Misconception:** You must know SQL (Structured Query Language) to work with Dataverse. **Reality:** Dataverse is fully manageable through a graphical, no-code interface in the Power Apps maker portal. SQL knowledge is optional, not required. (IT beginners hear ‘database’ and immediately think of complex coding languages. The Power Platform brand of ‘low-code/no-code’ deliberately hides this, but many learners do not believe it at first.)
- **Misconception:** Dataverse and Power Apps are the same thing. **Reality:** Power Apps is the tool to build apps that use data. Dataverse is the data storage and management layer that Power Apps (and other tools) connect to. They are separate components. (The way Microsoft markets the Power Platform often shows them together, so learners conflate the two. The exam specifically tests whether you can distinguish the data layer from the app layer.)
- **Misconception:** Dataverse requires an internet connection at all times to work. **Reality:** Dataverse is cloud-based, but Power Apps (which uses Dataverse) can work offline using a feature called offline sync. Data changes are cached locally and synced when the connection returns. (People assume the cloud means ‘always online’. Microsoft does offer offline capabilities, which surprises learners who have only used web apps that stop working when offline.)
- **Misconception:** You can only store business data in Dataverse, not files or images. **Reality:** Dataverse has columns of type ‘Image’ and ‘File’ that can store binary data such as photos, PDFs, and documents directly. (Beginners think of Dataverse as only handling text and numbers because that is what traditional databases do. Dataverse expands on this with richer data types.)

## Key takeaways

- Microsoft Dataverse is a cloud-based relational database service that stores business data and enforces rules about that data.
- Dataverse uses tables, columns, and relationships to organise data, much like a blueprint organises a building.
- Every Dataverse environment has its own security roles, which control who can read, write, delete, or share data in each table.
- Business rules in Dataverse run automatically to validate data (e.g., 'if status is Delivered, date must be provided') without needing code.
- Dataverse is the single data foundation that Power Apps, Power Automate, and Power Virtual Agents all use — data is written once and used everywhere.
- Dataverse comes with pre-built standard tables (like Account, Contact, Activity) that you can use immediately or extend with custom columns.
- You do not need to know SQL or any programming language to set up and use Dataverse; everything is done through a graphical interface.
- Dataverse integrates natively with Microsoft 365 and Dynamics 365, making it easy to connect business processes across the Microsoft ecosystem.

## FAQ

**Is Dataverse free to use with Power Apps?**

No. Dataverse requires a license. You get a small amount of storage with some Power Apps plans (like Power Apps per user plan), but for production use you typically need a paid license that includes Dataverse capacity.

**Can I connect Dataverse to an external database like SQL Server?**

Not directly. Dataverse is a separate database. You can move data into and out of Dataverse using Power Automate flows or custom connectors, but it does not act as a gateway to an existing SQL Server database.

**What happens if I delete a column in Dataverse?**

All data stored in that column is permanently deleted. You cannot undo this. Always export data before deleting a column. The deletion is immediate across the entire table.

**Does Dataverse work with non-Microsoft apps like Salesforce or Google Sheets?**

Yes, but through connectors. You can use Power Automate or custom connectors to push data from Salesforce into Dataverse, or use the Dataverse API to connect third-party applications. It is not a native integration.

**How is Dataverse different from a SharePoint list?**

SharePoint lists are simple flat lists with basic validation. Dataverse supports relationships between tables, complex business rules, automated workflows, and much richer security. For anything beyond a simple list, Dataverse is the better choice.

**Do I need to know coding to create relationships in Dataverse?**

No. In the Power Apps maker portal, you can create relationships using a graphical drop-down interface. You select the two tables and the type of relationship (one-to-many or many-to-many) — no code required.

## Check your understanding

1. **What is the primary purpose of Microsoft Dataverse in the Power Platform?**

   Answer: Dataverse is the centralised data storage and management layer that provides a secure, relational database for Power Apps, Power Automate, and Power Virtual Agents.

2. **Which Dataverse feature ensures that every order is linked to a valid customer?**

   Answer: A relationship (specifically a one-to-many relationship) between the 'Customer' table and the 'Order' table enforces that each order belongs to an existing customer.

3. **What is the difference between a Dataverse business rule and a Power Automate flow?**

   Answer: A business rule runs directly on a table for simple validation and field updates, while a Power Automate flow handles complex multi-step processes and can involve external services.

4. **Where do you configure who can read, write, or delete records in a Dataverse table?**

   Answer: In the security roles section of the environment, where you assign table-level permissions to users or teams.

5. **True or False: You must write SQL code to create relationships between tables in Dataverse.**

   Answer: False. Relationships are created using a graphical interface in the Power Apps maker portal, with no code required.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/pl-900/power-platform-dataverse