DIALOGE — D: Data¶
Data is the foundation. Every other building block depends on it.
TL;DR
Data is the foundation — get it wrong and everything compounds. Choose Dataverse for enterprise solutions. Design security roles by job function (never one role for all). Enable auditing on sensitive tables. Classify data before building. Use application users for integrations, never personal accounts.
Applies To
Audience: Solution Maker · Solution Engineer BOLT Tiers: Tier 2–4 (Tier 1 uses SharePoint only) Maturity: Basic → Advanced Frameworks: DIALOGE · SHIELD (Harden — data classification)
What Data Means in DIALOGE¶
Every solution needs a place where information lives, a structure that organises it, and rules that govern who can access, modify, and move it.
Data is not just storage. It is the contract between your solution and the real world — defining what information matters, how it relates, who can see it, and how long it lasts.
Poor data decisions compound over time. A solution built on unstructured, unclassified, or ungoverned data creates technical debt, security risk, and compliance exposure that becomes increasingly expensive to fix as adoption grows.
Why Data Decisions Matter¶
Most solution failures can be traced back to a data decision made early — or not made at all:
- A solution built on SharePoint lists that outgrows them at 10,000 rows
- Sensitive data stored without classification, discovered during an audit
- No data owner — nobody responsible when records are corrupted or lost
- Duplicate data created instead of integrating with the system of record
- No retention policy — data accumulates indefinitely, storage costs grow unexpectedly
Getting the data layer right from the start is the single highest-leverage investment a builder can make.
Key Decisions Every Builder Must Make¶
Before writing a single line of logic or designing a single screen, answer these:
- Where does the data live? Internal vs external, cloud vs on-prem, existing system vs net new
- What is the structure? Relational tables, flat lists, unstructured documents, hierarchical records
- Who owns it? Business owner, IT owner, or shared — someone must be accountable
- How sensitive is it? Public, internal, confidential, or regulated (PII, financial, health, legal)
- How long do we keep it? Retention period, archival policy, deletion schedule
- Does it already exist somewhere? Integrate with the system of record rather than duplicate
- Does it need to move? Across systems, across geographies, across organisational boundaries
Maturity Levels¶
| Level | Description | Suitable For |
|---|---|---|
| Basic | Data exists and is accessible. No formal structure or governance. | Personal productivity solutions with non-sensitive data |
| Intermediate | Structured schema with defined ownership and basic access controls. | Team or departmental solutions |
| Advanced | Classified, governed, auditable, retention enforced, data lineage tracked. | Enterprise or regulated workloads |
Safe Zone¶
Solutions using only standard, non-sensitive internal data with no regulatory requirements can operate at Basic or Intermediate maturity.
Any solution touching PII, financial, health, or regulated data must reach Advanced maturity before Go-Live.
When in doubt, classify higher. Reclassifying data downward is straightforward. Discovering unclassified regulated data during an audit is not.
Power Platform Data Options¶
| Option | When to Use | When Not to Use |
|---|---|---|
| Dataverse | Enterprise solutions requiring security, governance, audit, and relational data | Simple personal productivity tools with no security requirements |
| SharePoint Lists | Simple low-complexity solutions, non-sensitive data, small teams familiar with SharePoint | Solutions with relational data, high row counts, or security requirements |
| Excel / OneDrive | Personal productivity only, single user, throwaway solutions | Any shared or production solution |
| Azure SQL | High-volume transactional data, complex queries, existing enterprise data architecture | Solutions where the full Power Platform data stack is preferred |
| External system via connector | Data already lives in Dynamics 365, Salesforce, SAP, or another system of record | When duplication is acceptable and integration is impractical |
| Azure Blob / SharePoint Libraries | Large file storage — documents, images, videos | Structured relational data |
Dataverse — The Enterprise Data Foundation¶
For enterprise solutions on Power Platform, Dataverse is the right data layer. Not because it is the only option — but because it is the only option that addresses all data concerns natively, at enterprise scale, without requiring separate tooling.
What Dataverse Is¶
Dataverse is a cloud-hosted, low-code relational data platform built into Power Platform. It is not just a database. It is a governed, secure, auditable data layer with:
- Built-in relational structure (tables, columns, relationships)
- Native business logic (business rules, calculated columns, rollup columns)
- Enterprise security (role-based access, row-level security, column-level security)
- Built-in auditing and compliance logging
- Native integration with every Power Platform product and the Microsoft ecosystem
- Storage management across structured data, files, and logs
When you build on Dataverse, governance is structural — not bolted on.
How Dataverse Addresses Every Data Decision¶
| Data Decision | How Dataverse Addresses It |
|---|---|
| Where does data live? | Cloud-hosted within your Microsoft tenant, in your chosen geographic region. Data residency is configurable for regulated workloads. |
| What is the structure? | Relational tables with typed columns, defined relationships, and enforced constraints. Standard tables (Account, Contact, etc.) provided out of the box. |
| Who owns it? | Environment-level ownership with named admins. Every table has an owner field. Business units create organisational hierarchy. |
| How sensitive is it? | Column-level security profiles restrict access to specific fields. Row-level security controls which records each user can see. |
| How long do we keep it? | Audit logging captures every create, update, and delete. Bulk delete jobs enforce retention policies. |
| Does it already exist? | Native connectors to Dynamics 365 (same data layer), Azure services, and 900+ external systems via Power Automate. |
| Does it need to move? | Dataverse API, Dataverse connector, Azure Synapse Link for analytics, and Dataverse change tracking for event-driven integration. |
Core Concepts Every Builder Must Understand¶
Tables¶
Tables are the fundamental unit of data in Dataverse — equivalent to a database table or spreadsheet, but with structure, security, and logic built in.
Standard tables — Microsoft-provided tables that represent common business concepts: Account, Contact, Activity, User, Team. Use standard tables wherever possible. They integrate with Dynamics 365, Microsoft 365, and the broader Microsoft ecosystem out of the box.
Custom tables — Tables you create for your specific business data. Name them clearly, prefix with your organisation's publisher prefix, and document their purpose.
When to extend vs create new: - Extend a standard table when your data represents the same concept (e.g. adding fields to Contact for your specific customer data) - Create a custom table when your data represents a genuinely new concept not covered by standard tables
Columns¶
Columns define the data structure within a table. Key column types to understand:
- Text, Number, Date/Time, Choice, Lookup — the everyday workhorses
- Calculated columns — values derived automatically from other columns; reduce logic duplication across apps
- Rollup columns — aggregate values from related records (e.g. total order value across all order lines)
- File and Image columns — store binary data directly in Dataverse; use sparingly as they consume file storage capacity
Design principle: Keep columns on the table, not in the app. If the same calculation appears in multiple apps, it belongs as a calculated column on the table.
Relationships¶
Relationships connect tables — defining how records relate to each other.
| Relationship Type | When to Use | Example |
|---|---|---|
| One-to-Many (1:N) | One parent record has many child records | One Account has many Contacts |
| Many-to-Many (N:N) | Records on both sides can relate to multiple records on the other | Many Products can appear in many Orders |
| Polymorphic (regarding) | A child record can relate to multiple different parent table types | An Activity can relate to an Account, Contact, or Opportunity |
Cascade behaviour — define what happens to child records when a parent is deleted or reassigned. Set this deliberately; the default behaviour is not always what you want.
Business Rules¶
Business rules are declarative logic applied at the table level — not in any individual app or flow. They fire whenever a record is created or updated, regardless of which app or interface triggered the change.
Use business rules for: - Field requirement rules (make a field required when another field has a specific value) - Default values based on other field values - Show/hide logic that applies across all apps using this table - Simple validation that should be enforced everywhere
Design principle: If a rule should always apply to this data, put it in a business rule. If it only applies in one app, put it in the app.
Views¶
Views are pre-defined, filtered, and sorted sets of records — reusable across every app that uses the table.
- System views — provided by Microsoft for standard tables
- Public views — available to all users with access to the table
- Personal views — created by individual users for their own use
Design your views once on the table. Every canvas app, model-driven app, and flow that uses this table can reuse them.
Security Model¶
Dataverse Security and SHIELD Harden
The security model described here (roles, RLS, CLS) implements the data protection controls defined in SHIELD Harden →. Design decisions made here generate the evidence that SHIELD Enforce → requires for audit readiness.
The Dataverse security model is one of the most powerful — and most misunderstood — aspects of the platform. Most security failures in Power Platform solutions come from a security model that was not designed, just accepted by default.
Security Roles¶
A security role is a collection of privileges that defines what a user can do with each table — create, read, write, delete, append, append to, assign, share — at defined scope levels.
Scope levels: - User — only records owned by the user - Business Unit — records owned by users in the same business unit - Parent: Child Business Units — records owned by users in the business unit and all child business units - Organisation — all records in the environment
Design principles for security roles: - Start with least privilege — grant only what is needed - Create roles by job function, not by person - Stack roles — a user can have multiple roles; privileges combine additively - Never modify the default System Administrator or System Customizer roles — create copies and customise those - Document every role: what it is for, who it is assigned to, when it was last reviewed
Business Units¶
Business units create an organisational hierarchy within a Dataverse environment. They are the primary mechanism for data isolation between organisational groups.
- Every user belongs to exactly one business unit
- Record ownership is tied to the owning user's business unit
- Security role scope (Business Unit, Parent: Child) uses the business unit hierarchy to determine data visibility
Use business units when different organisational groups need to be isolated from each other's data within the same environment — for example, different regions, departments, or subsidiaries.
Row-Level Security¶
Row-level security controls which records a user can see — not just which tables they can access.
Implemented through: - Security role scope (User, Business Unit, Organisation) - Record sharing — explicitly sharing individual records or views with specific users or teams - Owner teams and access teams — granting access to groups of records via team membership
Column-Level Security¶
Column-level security restricts access to specific fields within a table — independent of the user's broader table access.
Use column-level security for: - Salary, compensation, or financial data - Social security numbers, national ID numbers - Health or medical information - Any field that should only be visible to a subset of users who otherwise have access to the table
Column-level security is implemented through column security profiles — assigned to users or teams separately from security roles.
Application Users and Service Accounts¶
When integrations, flows, or external systems need to access Dataverse, they should use a dedicated application user — not a personal user account.
- Application users are non-interactive, non-licensed accounts associated with an Azure AD app registration
- They have security roles assigned like any other user
- Using personal accounts for integrations creates dependency on individuals and breaks when people leave
Design principle: Every integration that writes to Dataverse should use a named application user with a least-privilege security role.
Auditing and Compliance¶
Dataverse auditing captures a record-level history of every create, update, and delete operation — who changed what, when, and what the previous value was.
Enabling auditing: - Auditing must be enabled at three levels: tenant (Admin Center), environment, and table - Enable auditing on all tables containing sensitive, regulated, or business-critical data - Not all columns need to be audited — be selective to manage log storage consumption
What audit data provides: - Complete change history for every audited record - User attribution — who made the change - Timestamp — when the change was made - Before and after values — what changed - Evidence for compliance frameworks (SOC2, ISO 27001, GDPR, HIPAA)
Retention: - Dataverse audit logs consume log storage capacity - Define a retention period appropriate to your regulatory requirements - Configure automatic log deletion to prevent unbounded storage growth
Connection to SHIELD: Dataverse auditing is the primary evidence source for the Enforce pillar of SHIELD — generating compliance evidence as a byproduct of normal operations rather than requiring manual evidence collection.
Storage and Capacity¶
Dataverse storage is divided into three categories — understanding each prevents unexpected cost overruns.
| Storage Type | What It Contains | Watch Out For |
|---|---|---|
| Database | Structured table data, metadata, business rules | Large datasets, many tables, rollup columns |
| File | File and image column attachments stored in Dataverse | Solutions using file/image columns at scale |
| Log | Audit log data | High-volume auditing without retention policies |
Common capacity mistakes: - Storing large files (documents, images, videos) as Dataverse file columns — use SharePoint or Azure Blob instead - Enabling auditing on every table and column without a retention policy — log storage grows indefinitely - Not baselining storage at go-live — unable to track growth or forecast capacity needs
Monitoring: - Review Dataverse capacity in the Power Platform Admin Center monthly - Set alerts before environments approach storage limits — storage overages block solution imports and create operational incidents
Common Mistakes¶
- Building on SharePoint lists and outgrowing them — migration to Dataverse mid-project is expensive and disruptive. If there is any chance the solution will grow, start with Dataverse.
- One security role for everyone — the default System Administrator or a single custom role assigned to all users is not a security model. Design roles by function from day one.
- Not using business rules — the same validation logic duplicated across three canvas apps and two flows. Put it on the table once.
- Ignoring column-level security — sensitive fields visible to everyone who has table access because column-level security was never configured.
- Using personal accounts for integrations — flows and integrations break when the person leaves. Always use application users.
- No retention policy on audit logs — log storage consumes capacity budget silently until it becomes an incident.
- Creating custom tables when standard tables exist — reinventing Contact, Account, or Activity instead of extending the standard table and inheriting its ecosystem integrations.
- Over-engineering the schema upfront — 40 tables designed before a single user has touched the solution. Start lean; extend as requirements are validated.
Dataverse Readiness Checklist¶
Structure - [ ] Decision made: Dataverse vs alternative data store — justified and documented - [ ] Standard tables identified and extended where applicable - [ ] Custom tables created only where no standard table applies - [ ] Relationships designed — type, cascade behaviour, and purpose documented - [ ] Calculated and rollup columns defined on the table, not in apps - [ ] Business rules implemented for logic that applies across all interfaces - [ ] Views designed and named clearly for reuse across apps
Security - [ ] Security roles designed by job function — not one role for all - [ ] Least privilege principle applied — minimum access required for each role - [ ] Business units configured if organisational data isolation is needed - [ ] Row-level security scope defined for each role on each table - [ ] Column-level security profiles created for sensitive fields - [ ] Application users created for all integrations — no personal accounts used - [ ] Security roles reviewed and documented — owner and review date recorded
Compliance - [ ] Auditing enabled at environment level - [ ] Auditing enabled on all sensitive, regulated, and business-critical tables - [ ] Audit log retention period defined and configured - [ ] Data classification assigned to all tables - [ ] Data residency verified for regulated workloads
Capacity - [ ] Storage baseline recorded at go-live - [ ] Capacity alerts configured in Admin Center - [ ] File storage strategy decided — Dataverse file columns vs SharePoint vs Azure Blob - [ ] Audit log retention policy in place to prevent unbounded log growth
Part of the DIALOGE Framework — powerplatform.wiki Last updated: March 2026 Last reviewed: March 2026