Introduction: Why the Terminology Matters
If you build or extend Dynamics 365 apps, you have likely noticed that Microsoft’s documentation now says table where it once said entity. The change is more than cosmetic: it reflects Dataverse’s ambition to feel familiar to database‑minded makers while still supporting the SDKs that developers rely on. Yet code samples, plug‑ins, and legacy blogs continue to use the word entity. Knowing when each term applies keeps your models clear, your API calls correct, and your team conversations smooth.
How We Got Here: From Entities to Tables
| Timeline | UI Term | Developer Term | Rationale |
|---|---|---|---|
| Pre‑Nov 2020 | Entity | Entity / EntityType | Original Common Data Service naming |
| Nov 2020 | Table | Entity / EntityType | UI made friendlier for citizen developers |
| Today | Table | Entity (SDK) / EntityType (Web API) | Mixed reality every developer must navigate |
Microsoft officially adopted table in the user interface during the November 2020 rebrand of CDS to Dataverse, mapping legacy terminology one‑to‑one (entity → table, attribute → column, record → row).
Understanding Each Perspective
1. The Maker View (Low‑Code)
- What you see: standard and custom tables in the Power Apps maker portal.
- Focus: naming consistency with Excel and SQL; drag‑and‑drop column creation; role‑based security; rich business rules.
- Key takeaway: think relationally—rows, columns, and relationships—even if Dataverse isn’t a traditional SQL schema.
2. The Pro‑Developer View (Code)
- What you code:
Entityobjects in the .NET SDK orEntityTyperesources in the Web API. - Why it hasn’t changed: backward compatibility. Renaming core classes would break thousands of solutions and ISV products.
- Tip: treat entity as “row instance” when writing plug‑ins (
public class Account : Entity) to avoid mental friction.
3. The Database Administrator’s View
- Reality check: Dataverse stores metadata‑driven information, not raw SQL tables. Behind the scenes your “table” may sit across many physical tables, partitioned for performance and security.
- Action: use the UI term “table” with stakeholders, but document logical design using the SDK names when sharing code snippets.
Practical Development Implications
| Feature / Task | UI Term | SDK / API Term | What to Watch For |
|---|---|---|---|
| Creating a schema object | Table | CreateEntityRequest | Still passes an EntityMetadata class |
| Adding a column | Column | Attribute / Property | Data type names differ slightly |
| CRUD operations | Row | Entity | SDK returns Entity.Id, not Table.Id |
| Security roles | Table permissions | Privileges (EntityName + privilege) | UI hides privilege names |
Because the SDK still exposes Entity, your plug‑ins and early‑bound classes remain valid. Only your interface labels and user docs need updating.
Best Practices for Mixing the Terms
- Be explicit in documentation. Write “Account (table), exposed as
accountentity in the SDK” the first time you introduce an object. - Name plug‑ins after the logical table. Example:
PreAccountCreate.cs—readable to makers and developers alike. - Use solution layers. Keep low‑code table customizations separate from pro‑code projects to avoid merge confusion.
- Stay current. Microsoft’s terminology table is updated periodically—bookmark the docs.
How Skysoft Accelerates Your Dataverse Journey
At Skysoft Connections we deliver:
- Schema Design Workshops – align your “table vs. entity” vocabulary and produce a future‑proof data model.
- Code Modernisation – refactor legacy plug‑ins, Web API calls, and JavaScript to the latest SDK patterns while maintaining entity compatibility.
- Power Platform Governance – set naming conventions, solution layering, and deployment pipelines that embrace Microsoft’s evolving terminology.
- Custom Portals & Power Apps – extend your new or existing tables into pixel‑perfect portals, mobile apps, and Power BI reports.
40 000+ billable hours, 100 % Upwork success, and a team ready to scale to the UAE—Skysoft handles the heavy lifting so you can focus on innovation.
Conclusion: Speak Both Languages, Ship With Confidence
In day‑to‑day development, entity and table are two lenses on the same Dataverse object. The UI speaks in tables to welcome makers; the SDK speaks in entities to preserve code‑base stability. Mastering the duality means fewer misunderstandings, smoother code reviews, and faster project delivery. Embrace the vocabulary—your Dynamics 365 solutions (and stakeholders) will thank you.
Read More : How a Custom Web Portal Can Boost Your Customer Engagement
FAQ’s
Yes, they refer to the same concept. “Table” is now used in the UI for a more user-friendly experience, while “entity” is still used in the SDK and APIs for compatibility with existing code.
Microsoft made the switch to align with common database and Excel terminology, making Dataverse easier to understand for non-developers and low-code users.
No, your code remains valid. The SDK still uses “entity” classes, so there’s no need to refactor unless you’re updating documentation or user-facing labels.
