Tables

Well‑designed tables form the foundation of every Dynamics 365 or model‑driven app. Good table design ensures consistency, reusability and maintainability across DfE’s CRM landscape. The guidance below outlines how to structure tables so they align with Microsoft best practice and DfE data standards.

Use out‑of‑the‑box tables where possible

Microsoft Dataverse provides a set of standard tables that are designed to support common business scenarios. Microsoft states that these out‑of‑the‑box (OOTB) tables are built “in accordance with best practices, to capture the most common concepts and scenarios within an organisation”.

Use these first before creating custom ones:

Account → represents organisations, businesses, schools, providers
Contact → represents people
Case → represents enquiries, interactions or case management processes

Using standard tables ensures:

Compatibility with OOTB Dynamics 365 and Power Platform features
Alignment with Microsoft's upcoming roadmap and new features
Reduced technical debt and easier upgrade paths

Avoid creating custom tables that duplicate the purpose of standard ones.

Create tables that support reuse

DfE delivers shared CRM capabilities across multiple programmes and business areas. Tables should therefore be designed to be generic enough for reuse, not narrowly tied to a single team’s processes.

Good example:

Application (generic across teams)

Poor example:

Apprenticeship Provider Application (team‑specific, not reusable)

It's recommended to consider tables carefully as part of an overall data model that supports multiple apps and processes.

Before creating a new table:

Check if an existing table already captures the concept
Review other programmes’ needs to avoid duplicates
Confirm alignment with the DfE corporate data model
Consider whether extending an existing table (e.g. with extra columns) is sufficient

Reusable tables help:

Reduce duplication
Maintain consistent reporting
Simplify integration
Keep the overall system consistent

Align tables to DfE’s corporate data models

DfE’s Data Directorate is producing organisation‑wide data standards, including:

Standard entity definitions
Data dictionaries
Naming and validation rules

Where these standards exist, table design must match the agreed patterns, particularly for repeatable tables such as:

Organisations
Contacts
Providers
Locations or regions

This ensures consistency across DfE systems and makes data easier to exchange, validate and process data.

Consistent naming conventions

Clear naming conventions help developers and analysts understand the purpose of each table.

Naming rules:

Use singular display names (e.g. Provider, Funding Application)
Plural Name should be a natural plural for use in views and sitemaps
Table purpose should be clear and understandable from the name
Avoid programme‑specific abbreviations or internal jargon

Schema name:

Use the dfe_ prefix for the publisher unless a specific environment requires another prefix
Keep schema names lowercase, as recommended for easier API referencing
Avoid renaming display names after creation - the underlying schema name cannot be changed later and can become misaligned

Table descriptions

Every table must have a meaningful description. Table descriptions are visible in the solution and help future developers understand purpose.

Data teams also use table metadata from solutions in order to generate a data dictionary for each application. Having meaningful table descriptions help data teams to understand the usage of each table.

Table type and ownership model

Table type and ownership settings cannot be changed after creation and should be considered carefully.

Guidance:

User/Team‑owned tables → use when permissions vary by team or individual
Organisation‑owned tables → use for reference data or configuration tables
Activity tables → use only when modelling communication or timeline‑based events which will be displayed alongside other activity types
Generally, avoid virtual tables unless a specific integration scenario requires them as they often come with limitations

Choosing the right type and ownership model ensures security roles and permissions behave as expected.