Tables and columns

What it does

Tables hold rows of business data, columns define what each row stores. Dataverse ships with a set of standard tables — account, contact, user, business unit, task and the rest — and you add custom tables alongside them. Every table has a type and an ownership model, and both are decided at creation time.

Key facts

Four table types appear in the maker portal: standard, activity, virtual and elastic. You pick the type on the New table panel under Advanced options, and you can't change it afterwards.
Ownership is User or team or Organization, chosen at creation and permanent. Get it wrong and your only route is delete and rebuild.
A handful of system tables sit outside those two options — Privilege has no owner at all, and Business Unit, Calendar, Team and Security Role are business-unit owned.
Activity tables can only be user or team owned. They don't get a primary column you choose; the primary field is always Subject, inherited from the Activity table.
The schema name picks up the customisation prefix from the solution publisher of whichever unmanaged solution you're working in. It can't contain spaces and can't be changed after save.
The primary column display name and description are locked once the table is saved.
Enabling Creating a new activity on a table is one-way. Once activities are on, they stay on.
Standard text columns top out at 4,000 characters; multiline text goes to 1,048,576. Lowering a max length doesn't truncate existing data, it only applies to new rows.

When to use / skip

Reach for a standard table first — account and contact carry a lot of platform plumbing (address handling, duplicate detection, connection roles, Dynamics 365 integration) that you'd otherwise rebuild badly. Create a custom table when the concept genuinely isn't one of the standards, not because the standard one has fields you don't like. Hiding unused columns is cheaper than owning a parallel data model forever. Elastic and virtual tables are specialist choices covered separately; if you're not sure, standard is the right answer.

Configuration decisions

Ownership type per table, decided before anyone creates a row, because it determines whether the security model can ever filter that table by user or business unit.
Which solution publisher prefix your custom schema carries, since it's stamped on every table and column and follows you for the life of the project.
Whether the table needs activities, notes, connections, queues or auditing — several of these are one-way switches.
Whether a concept is a table or a column on an existing table. A lookup to a five-row config table is often a choice column in disguise.
Naming convention for display names versus schema names, and who enforces it.

Gotchas

Ownership is the one that hurts. An organisation-owned table can't be filtered by owner or business unit in a security role — the only access levels are effectively yes or no. Teams discover this after go-live.
The publisher prefix comes from the solution you happened to have open, not from the table. Makers working in the default solution end up with cr123_ prefixes scattered through the schema.
Deleting a custom table deletes its data, and cascades to anything in a parental relationship with it. Restore from backup is the only recovery.
Required columns on a hidden tab or section don't block a save unless the same column also sits somewhere visible on the form. That surprises people debugging validation.
Only SystemRequired columns are enforced when rows are written through the API. Business-required is a client-side courtesy — integrations sail straight past it.

Consultant notes

Run a table design review before anyone builds. Ownership type and prefix are the two decisions that cost real money to reverse, and both take thirty seconds to get right up front.
Push back on "we need a custom Account". Nine times in ten the requirement is a few columns and a view, and the client is really asking for the standard table with their labels on it.
Warn the client that turning auditing on per table is easy and turning it off later doesn't reclaim the log storage already consumed.
Agree naming standards in writing at kickoff, including who owns the publisher. Retro-fixing schema names means rebuilding columns and remapping everything that touches them.

Worth a look again if the data workspace designer picks up the table types it currently can't create, or if ownership ever becomes changeable.