Behind the Names: Unlocking Schema and Logical Names in Dataverse

Schema and Logical Names in Dataverse form the backbone of how data is structured, stored, and referenced within the platform. The Schema Name is a system-level, immutable identifier created when a table or column is generated; it is mainly used by developers, plugins, integrations, and API calls. It follows a strict format (prefix + name) and does not change even if the display name changes, ensuring long-term stability for solutions and custom code. The Logical Name, on the other hand, is the programmatic name Dataverse uses internally and externally when accessing data through the Web API, SDK, Power Automate, or Power Apps. Logical names are unique and aligned to the physical storage in the Dataverse database. While schema names provide structure and a consistent metadata definition, logical names enable efficient data operations and integration. Together, they create a reliable separation between user-friendly labels and system-driven identifiers, ensuring stability, consistency, and compatibility across environments, solutions, and automation.

Where Logical Names Are Used

• C# plugin code: entity["crbe_firstname"]
• JavaScript: formContext.getAttribute("crbe_firstname")
• Web API: /api/data/v9.2/crbe_customerfeedbacks
• Power Automate Dataverse actions

Why Logical Name Matters

• The system executes using this name
• Changing display names has no effect
• Used by all backend components
• Ensures stable API integrations

Best Practices for Dataverse Naming Conventions

Good naming conventions improve readability, governance, extensibility, and integration across Power Apps, Power Automate, Azure, and external systems.

Publisher Prefix

Every table, column, and relationship should start with a unique publisher prefix.

Why?

• Avoids collisions with Microsoft standard entities
• Helps identify your solution components easily
• Mandatory for ALM and managed solutions

Example:

Display Name vs Schema Name vs Logical Name

Follow the expected structure:

Table Naming Conventions

Use singular nouns

• Good: Customer, Invoice, CardList
• Avoid plural: Customers, Invoices

Avoid acronyms unless industry-standard

• Good: GSTNumber
• Not good: GN

Prefix custom tables

• abc_CardLististLink

Use clear functional names

• Not: abc_DetailTable
• Use: abc_AccountRiskAssessment

Column Naming Conventions

• Use PascalCase for schema name
• abc_IsBlacklisted
• abc_ConsumptionPerMonth

Boolean fields → prefix with Is, Can, Has

• abc_IsPrimary
• abc_HasActiveSubscription
• abc_CanBeBlacklisted

Lookup fields → suffix with Id

• abc_ContactId
• abc_AccountId

Choice fields → end with Type or Status

• abc_CustomerType
• abc_ApplicationStatus

Date fields → end with Date

• abc_ApprovalDate
• abc_InvoiceDate

Relationship Naming Conventions

One-to-Many

• Format:
• publisherPrincipalTable_dependentTable

Example:

• abc_Account_CardAccount

Many-to-Many

• Format:
• publisherTable1_Table2

Example:

• abc_Account_Opportunity

View Naming Conventions

• Always include
• Purpose
• Filter Criteria

Example:

• Active Card Accounts
• Expired Licenses (Last 30 Days)
• Accounts With Blacklisted Cards

Form Naming Conventions

• Format:
• Main – Purpose
• Quick – Purpose

Examples:

• Main – Blacklist Management
• Quick – Contact Summary

Business Process Flows

Include scope + purpose

• Account – Onboarding Process
• CardAccount – Blacklisting Review

Power Automate Flow Naming

• Format:
• System/Team – Entity – Action – Additional Info

Examples:

• Ops – Account – Populate Blacklisting
• CRM – Lead – Convert to Account
• Finance – Invoice – Send Reminder Email

Security Role Naming

• Format:
• App – Role Level

Examples:

• Cards – Administrator
• Cards – Read Only
• Sales – Manager

General Rules to Follow

Why Dataverse Has Schema Name AND Logical Name (Technical Reasons)

Dataverse maintains two separate names for every table, column, and relationship because each name serves a different technical purpose in the platform.

Schema Name is for Solution Layer (Design-Time Metadata)

Technical Purpose

• Identifies components inside a solution
• Used by solution packaging, deployment, and ALM
• Required during component references in forms, views, relationships
• Supports PascalCase for readability
• Must be stable for export/import across environments

This name stays consistent inside all managed/unmanaged solution files.

Why Needed?

• Metadata in solution.xml, customizations.xml, and relationship.xml uses schema names.
• Ensures deterministic referencing, meaning solutions can be reliably imported/exported.

Logical Name is for the Runtime Layer (Database + API)

Technical Purpose

• Used by Dataverse database engine
• Used in Web API, OData, SDK, and Plug-ins
• Lowercase + underscores → URL-safe and API-friendly
• Optimized for querying, joins, filter expressions, and indexing

Why Needed?

Dataverse runs on a highly optimized distributed storage engine under the hood.

Logical names give consistent internal naming:

• For database tables/columns
• For runtime metadata lookups
• For Web API routes (/api/data/v9.0/abc_customers)

Logical names cannot change once created — changing runtime names would break every API, plugin, and integration.

Schema Name Supports Readability — Logical Name Supports Machine Execution

Schema Name

• PascalCase
• Easy for developers & solution designers
• Visible mainly inside apps (Power Apps Studio, Solution Explorer)

Logical Name

• Lowercase
• Must follow strict technical rules
• Used internally by Dataverse engine & APIs

Backwards Compatibility Across Versions

Dataverse (formerly CRM) has been evolving since 2003.

Keeping two naming layers allows:

• UI & metadata naming (schema name) to evolve

while

This prevents breaking:

Schema Name = for developers

Logical Name = for machines