The name turns up long before anyone defines it
Dataverse is the shared data store underneath Power Apps, Power Automate, Dynamics 365 and Copilot Studio. It holds business records in tables, and it holds the rules about those records in the same place, so anything that writes a row passes the same checks. That second half is the part nobody explains, and it is most of the reason the product exists.
Most people meet the name sideways. A maker building a first app sees Dataverse offered as somewhere to put data, sitting next to a SharePoint list and a file in OneDrive. A Dynamics 365 administrator hears that their sales records already live there. Someone in procurement hears the word attached to a premium licence and asks what it buys. Three true answers that do not add up to an explanation.
Three descriptions get repeated and none of them survives a real build. Dataverse is not SharePoint lists with a bigger price tag, because lists have no relational model worth the name and no way to stop one column being read by the wrong person. Dataverse is not a hosted SQL Server you can point any tool at, because there is no connection string to hand out and every read and write goes through a governed API. Calling it a database is accurate and incomplete, and the missing part is what people are actually paying for.
Tables and relationships you only define once
Start with the model, because everything else hangs off it. A Dataverse table has typed columns, and the types carry meaning the platform enforces. A choice column has a defined set of options with labels and stored values, so two apps cannot invent their own spelling of Awaiting Approval. A lookup column points at a row in another table and the platform knows that relationship exists.
Relationships are declared once and honoured everywhere. Set a one to many relationship between account and service visit, decide what should happen to the visits when an account is deleted, and that decision holds whether the delete arrived from a model driven app, a flow, a bulk import or the API. In a spreadsheet, the same decision lives in whoever remembers to tidy up afterwards.
The model also carries the things a raw table leaves to convention. Alternate keys let you address a row by the customer number the business already uses, so an upsert can land without a GUID lookup first. Display names and descriptions travel with the table into every app and every report, so the finance analyst building a Power BI view reads the same field label the service desk reads. Choosing between a custom table and a standard entity is the first real design argument most teams have.
The security model sits below every app
The part that surprises people arriving from lists is that Dataverse decides who can see a row before any app asks for it. Access comes from a user's security roles, the business unit they sit in, the teams they belong to, and who owns the row. A canvas app cannot widen that. Build a screen that queries every service visit and a technician still gets back only the visits they are entitled to see.
Row level control gets the attention. Column level control is the one that saves an audit. Mark a column as restricted and only the profiles you name can read or change it, whichever app, flow or report reached for it. I have used that on a supplier table where twelve people needed the record open in front of them and two people needed the bank account number.
This matters most on the day someone builds a report you did not know about. A Power BI model reading Dataverse can pass the viewer's identity through, so the same row filters apply in the report that apply in the app. The equivalent query against a plain SQL database returns everything the service account can reach, and the service account usually reaches everything. Where business logic should live is the same argument one layer up.
Logic that holds whoever wrote the row
A field service client of mine ran three apps against the same equipment records. A technician app on phones, a scheduling app for the back office, and a supplier portal. All three had to stop anyone booking a service visit against a decommissioned asset. All three had that check written into the screen, by three different people, in three different quarters.
The three screen checks did not agree. The technician app blocked the save outright. The scheduling app showed a warning and let you continue anyway. The portal did not check at all, because the developer who built it had been told the rule lived in the app and fairly assumed that meant his app. Then a nightly import from the asset register wrote forty visits against retired equipment, and none of the three apps was involved.
We moved the rule down into the table. A business rule handled the simple condition, and a plug-in registered on create and update handled the part that had to compare the asset retirement date with the visit date. After that the rule ran for the phone app, the back office app, the portal, the nightly import, and a Copilot Studio agent that nobody had planned for at the time. One rule, one place, one behaviour to test.
Calculated and rollup columns close the same gap for numbers. A count of open visits per account, computed by the platform, is the same number in the app, in the report and in the flow that escalates it. A count computed separately in each client is three numbers that agree right up until someone edits one of them.
When a spreadsheet is still the right answer
None of this is free, and plenty of work does not need it. A five person team tracking twenty pieces of equipment in a spreadsheet has no row level security problem, no second app, and no integration. Moving them into Dataverse buys them per user licensing, an environment strategy, a solution and deployment process, and capacity to keep an eye on. It buys them nothing they were missing.
The signals that change the answer are specific. More than one app or automation writes the same records. People who must not see each other's rows share a table. A rule has to hold when data arrives from an import or an API rather than from a screen. Somebody will eventually need a change history they can produce for an auditor. Hit two of those and the platform starts paying for itself.
Cost lands in two places teams underestimate. Storage and capacity, which is worth modelling before it surprises you, and the daily discipline of moving changes between environments. A Dataverse build without an environment strategy turns into a production environment that everyone edits directly, which throws away the main reason for choosing a governed platform.
The question to take into your next design review
Ask where each rule has to hold. Write down every rule the business would be embarrassed to break, then list every route a record can take into the system: the app, the flow, the nightly import, the partner integration, the agent somebody will build next year. If a rule has to survive all of those routes, it belongs in the store, and Dataverse is the Microsoft answer to that requirement.
If every rule only has to hold inside one app that three people use, keep the spreadsheet and spend the budget somewhere it will be noticed. Nobody has ever been thanked for putting a kit list into a governed platform. The teams I have watched regret their decision went the other way, and they were still copying the same validation into a fourth app the week the auditor arrived.
