Tables and columns with real types
Each entity in your business gets a table, a primary name column, and columns typed as dates, decimals, currency, lookups, or files — not eleven text fields that happen to hold numbers on a good day.
Microsoft Dataverse consulting services
Microsoft Dataverse consulting services for the data model under your Power Platform
Senior US-based engineers design the layer nobody sees and everything depends on: the tables your records actually live in, the relationships between them, the choices and rules that keep them clean, the security roles that decide who reads which row, and the environments and solutions the whole thing is promoted through. Sized against your real Dataverse capacity and license position, delivered in your own tenant for one written price, typically in 2–4 weeks with 30 days of hypercare.
Representative dashboard — sample data
What you get
The schema decisions that are expensive to change later
Screens can be redrawn in an afternoon. A table that was modeled wrong, or a security role that was never mapped to a real job, is the thing that gets rebuilt at year two. This is that work, done first.
Relationships instead of copied text
One-to-many and many-to-many relationships connect the records that belong together, with cascade behavior chosen deliberately, so deleting a parent does the thing you meant rather than the thing that was default.
Choices defined once, used everywhere
Status, category, and priority become global choice sets rather than free text. Reporting stops splitting the same value four ways, and an agent asked about open work gets one honest answer.
Security roles mapped to actual jobs
Privileges are granted at the level the work happens — the user's own records, their business unit, or the whole organization — with teams and column-level security where a field is more sensitive than the row it sits on.
Logic that holds outside the screen
Business rules, required columns, calculated and rollup values live in the platform, so a record created by a flow, an import, or the API obeys the same constraints as one typed by a person.
Environments and solutions, not live edits
Development, test, and production environments with the schema carried between them in solutions, so a column added six months from now is a reviewed release rather than somebody changing production at 4pm.
How it works
Three steps from a whiteboard model to a governed system of record
- 1
Model the business, on paper first
A free consultation covers what things you track, how they relate, which values are fixed, who may see what, and what already exists in SharePoint, Excel, or a legacy database. You get an entity-relationship sketch, a written scope, one fixed price, and a date.
- 2
Build the schema and the security
Tables, columns, relationships, global choices, keys, calculated and rollup columns, business rules, and auditing go in inside a development environment. Security roles, business units, and teams are configured and then tested by signing in as each role rather than reading the matrix back.
- 3
Migrate, promote, hand over
Existing records are mapped and loaded with duplicates resolved, the solution is promoted through test to production, capacity and licensing are confirmed against real usage, and you get a data dictionary, a walkthrough, and 30 days of hypercare.
What a Dataverse engagement covers
Microsoft Dataverse is the managed data platform that sits under Power Platform and Dynamics 365. Microsoft's Dataverse documentation (opens in new tab) describes it as a service for securely storing and managing data used by business applications: data lives in tables, tables have typed columns and relationships, and the platform — not each individual app — enforces the rules and the permissions. That distinction is the whole reason this page exists as its own service.
The engagement delivers a designed, documented data layer in your own tenant: the entity-relationship model, the tables and columns, the relationships and cascade behavior, global choice sets, alternate keys where a record must be unique, calculated and rollup columns, business rules, auditing configuration, security roles with business units and teams, the environments and solutions it all promotes through, a written capacity and licensing position, and a data dictionary somebody can read in two years. The work is performed remotely by senior US-based engineers from our Orange County, CA base, serving every US state, at a fixed fee agreed after your free consultation.
Where this stops and the app build starts
These are two different purchases and it is worth being blunt about the line. An app project is about what people touch: screens, forms, views, navigation, the offline experience on a phone. This project is about what those screens write into — and the same model usually serves several apps, a set of flows, a report, and eventually an agent, none of which existed when the first screen was drawn.
So the two are complementary rather than competing. If you need the interface built as well, our custom Power Apps development service covers canvas and model-driven builds on top of exactly this kind of model. If the users are customers, partners, or the public rather than licensed staff, the front door is Power Pages development, where site visitors reach Dataverse rows through web roles and table permissions. And where records need to move between people, Power Automate approval and integration flows ride on the tables built here rather than on a mailbox.
Dataverse is a system of record, not a pipeline
Teams often ask us to compare this with a data integration project, and the answer is that they solve opposite problems. A pipeline copies data that already exists somewhere else, on a schedule, into somewhere it can be reported on — that is our Azure Data Factory consulting service, and it is the right answer when the source system is staying put. Dataverse is where the record is created in the first place: written once, validated on write, secured per row, and audited. Nothing is being copied, so nothing can be stale.
The two do meet. Virtual tables let Dataverse present data that physically lives in another system without copying it, which is often cheaper than a nightly load for reference data. Going the other way, the built-in Link to Microsoft Fabric feature makes Dataverse tables available in Microsoft OneLake (opens in new tab) without exporting anything or building ETL, which is usually how a Dataverse-backed process ends up in analytics.
What we model, and what gets built for each part of it
Every business is different, but the modeling decisions fall into a small number of shapes. The table below is the pattern library we work from; the model in your written scope is a filled-in version of it.
| What you are modeling | How Dataverse holds it | What gets built |
|---|---|---|
| The things your business tracks — jobs, assets, cases, contracts | Custom tables with a primary name column and typed columns for dates, decimals, currency, files, and images | Table and column schema with display names people recognize, plus alternate keys where a record must be unique or matched on import |
| How those things relate — a job has many tickets, a contact works at many sites | One-to-many and many-to-many relationships, with cascade behavior set per relationship | Lookup columns, deliberate delete/assign/share cascade rules, and relationship names your reports and flows can follow later |
| Fixed sets of values — status, category, priority, region | Choice columns backed by global choice sets when the same list is used in more than one place | One definition per list, so a report, an app, and an agent all describe the same record with the same word |
| Values derived from other values — totals, counts, ages, margins | Calculated, rollup, and formula columns computed by the platform on the row itself | Numbers maintained by Dataverse rather than by a flow somebody has to remember to re-run after a backfill |
| Rules that must hold no matter who writes | Business rules, required and business-recommended columns, and validation applied at the data layer | Constraints that apply equally to the app, an import, a flow, and the API — instead of logic that only exists on one form |
| Who may see or change a given row | Security roles and privileges scoped to user, business unit, parent-child business units, or organization, plus teams and column-level security | Roles named after real job functions, tested by signing in as each one, with sensitive columns restricted separately from their rows |
| Changes that later have to be proven | Table-level and column-level auditing with a retention position | Auditing switched on for the columns that matter, documented so the audit log is a decision rather than an accident |
Security roles, business units, and the part everyone underestimates
Row-level security is the single most common reason a Dataverse project takes longer than a team expected, because it forces an organizational question that had never been written down: who is allowed to see whose work. In Dataverse, a security role grants privileges — create, read, write, delete, append, append to, assign, share — and each privilege is granted at an access level, from the user's own records up through their business unit and its children to the entire organization. Microsoft's security roles and privileges documentation (opens in new tab) sets out how those combinations are configured.
In practice we start from the org chart rather than from the table list, define the business units that genuinely need separation, use owner and access teams for the cross-cutting cases, and reserve column-level security for the handful of fields — salary, margin, personal identifiers — that are more sensitive than the record they belong to. Then we test it by signing in as each role, because a permission matrix that reads correctly and behaves incorrectly is the normal outcome otherwise.
Environments, solutions, and getting changes to production safely
A Dataverse database belongs to an environment, and an environment is the security and deployment boundary for everything in it. Production data does not belong in the same place as half-finished tables, so we set up development, test, and production environments and move the schema between them inside solutions, following Microsoft's application lifecycle management guidance for Power Platform (opens in new tab).
The practical payoff is that your model becomes changeable. Unmanaged solutions hold the work in development; managed solutions carry it downstream; environment variables and connection references keep the settings that differ per environment out of the components themselves. That is the difference between adding a column next year in ten minutes and being told the change is too risky to attempt on a live system.
Capacity and licensing, decided before you buy
Dataverse is not free storage, and this is where projects get an unpleasant surprise. Capacity is pooled at the tenant level and reported in the Power Platform admin center in three separate buckets — database, file, and log — and Microsoft's Dataverse capacity storage documentation (opens in new tab) explains how entitlement and consumption are reported against each.
What that means for scoping is concrete. Entitlements accrue from the licenses you already own, and premium Power Apps or Dynamics 365 seats add to the pool; attachments and images consume file capacity rather than database capacity; auditing consumes log capacity, which is exactly why "audit everything" is a decision and not a default. We look at your actual license position, estimate row volume and attachment growth from your real process, and tell you in writing whether your existing entitlement covers it. We do not resell licenses, so there is nothing in it for us either way. Our fee is fixed and separate; anything Microsoft charges is billed by Microsoft, directly to you.
What reads the model once it exists
A well-built Dataverse model is rarely used by one thing. Apps read and write it, flows react to it, and reporting sits on top: once real records accumulate, a fixed-fee Power BI dashboard turns them into the reporting leadership actually opens, without the export-to-Excel step in between. Agents are the newest consumer — Dataverse tables can be attached as a knowledge source or read through an action, which is what our Copilot Studio consulting services build on, and an agent grounded in typed, secured tables gives far better answers than one pointed at a folder of spreadsheets.
Dynamics 365 belongs in the same picture. The first-party sales, service, and field service apps store their data in Dataverse too, in standard tables such as account and contact, so a custom model built alongside them extends what is already there instead of duplicating it. That is also the honest test for whether you need this work at all.
Who this fits — and who it does not
It fits organizations whose process has outgrown a flat list: records that genuinely relate to other records, more than one team who must not see everything, values that have to be validated regardless of how they arrive, or a change history somebody may have to defend. It also fits teams who already have a Power App that works but is quietly held together by lookups into a spreadsheet.
It does not fit a single simple form with a handful of fields and no sharing rules; a SharePoint list is cheaper and we will say so during scoping rather than after. It is also not a data warehouse. If the goal is analytics over data that lives in other systems, the pipeline work comes first and the reporting work follows. Our fixed-fee process page sets out how the written scope is produced, what happens at handover, and what the 30 days of hypercare cover.
Delivery in three phases
The table shows scope and typical timeline rather than prices, because an honest number requires seeing your entity list, your security requirements, and what data has to be migrated in.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — model and agree | Entity-relationship model produced with your team, environments created, naming and publisher prefix agreed, license and capacity position confirmed, and the whole model signed off in writing before a table is built | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — build and secure | Tables, columns, relationships, global choices, alternate keys, calculated and rollup columns, business rules, and auditing built in a development environment, with security roles, business units, teams, and column-level security configured and role-tested | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — migrate and promote | Legacy records mapped and loaded with duplicates resolved and counts reconciled, solution promoted through test to production, connections and environment variables configured, plus a data dictionary, an admin walkthrough, and handover | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Everything produced is yours from day one. The environments, the tables, the solution files, and the data all live in your own Microsoft 365 tenant, never in ours, and the model can be extended by your own team or another partner without us in the loop.
Related services
What usually sits on top of the model
Power Apps Consulting
Canvas and model-driven apps — the screens, forms, and views your people use to work with these tables.
Copilot Studio Consulting
Custom agents grounded in your Dataverse tables, with actions, testing, and a credit forecast before capacity is bought.
Power BI Dashboards
Semantic modeling and report development over the records your Dataverse tables accumulate.
Further reading
Guides worth reading before you scope this
Hand-written guides from our article library.
Power Apps vs buying software
Where Dataverse licensing lands in a build-versus-buy comparison, with both sides costed over three years.
Signs you have outgrown Excel
The symptoms that show a workbook has quietly become a system of record it was never designed to be.
Fixed fee vs hourly consulting
Why we scope in writing before starting, and what that changes about who carries the risk.
FAQ
Data model questions, answered
Dataverse is the managed data platform behind Power Platform. Your business records live in related tables with typed columns, choices, rules enforced at the data layer, row-level security, and an audit history. Every app, flow, agent, and report then reads one governed definition rather than its own private copy.
A Power Apps engagement delivers the screens people use. This one delivers the model underneath them: tables, relationships, choice sets, calculated and rollup columns, business rules, and security roles. The two are often bought together, but the data design is the part that decides whether the app survives its second year.
Lists are fine for a short, flat set of records with simple sharing. Dataverse earns its licensing when you need real relationships between records, uniqueness enforced by a key, rules that hold no matter which client writes, row-level security by team or business unit, and column-level auditing.
Dataverse capacity is pooled at the tenant and reported as database, file, and log storage in the Power Platform admin center. Entitlements accrue from the licenses you already hold, and premium Power Apps or Dynamics 365 seats add more. We size it during scoping so nothing is bought blind.
No. A pipeline moves copies of data between systems on a schedule, which is what our Azure Data Factory work does. Dataverse is the system of record itself — the place the transaction is written, secured, and audited first. Some projects need both, in that order.
Everything lives in your own tenant and your own environments: the tables, the security roles, the solution files, and the documentation. The fixed fee reflects how many tables and relationships are modeled, how complex the security is, and whether legacy data has to be migrated in. Typical delivery is two to four weeks.
Book a free consultation
Get more from the Microsoft tools you already pay for
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
- Fixed-fee scope agreed before any work starts
- Senior, US-based Microsoft engineers — no handoffs
- Typical 2–4 week delivery
- 30 days of post-delivery hypercare included
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.