Skip to main content

Notifications

Announcements

No record found.

Microsoft Dynamics 365 | Integration, Dataverse...
Suggested answer

Distinguish between MS config tables to business tables

(1) ShareShare
ReportReport
Posted on by 1
For our integration to export business critical data from Dataverse, we'd like to distinguish programatically the tables that carry actual business data (like accounts, contacts and customers custom tables) and more configuration like data - which is currently the majority of Dataverse - examples: msdyn_fieldservicesystemjob, msdyn_msteamssetting, plugintracelog
Categories:
  • Suggested answer
    Amit Katariya007 Profile Picture
    Amit Katariya007 8,670 Super User 2024 Season 1 on at
    Distinguish between MS config tables to business tables
    To programmatically distinguish between tables carrying business-critical data and configuration or system-related data in Dataverse, you can leverage the table metadata provided by the Dataverse Web API or the SDK. Specifically, you can use the IsCustomEntity and OwnershipType properties, as well as naming conventions and metadata like table prefixes or descriptions. Here's how you can achieve this:
     
    Steps to Identify Business-Critical Tables
    1. Check Metadata for IsCustomEntity
    Custom tables typically have IsCustomEntity set to true.
     
    Business-critical tables (like account, contact, or custom tables) are often custom or standard business tables.
     
    Example Query:
    Use the Web API to query metadata:
     
    GET [Organization URI]/api/data/v9.2/EntityDefinitions?$select=LogicalName,IsCustomEntity,DisplayName
     
    Filter for IsCustomEntity=true for custom business data tables.
     
    2. Filter by OwnershipType
    Business data tables are usually user-owned (UserOwned) rather than organization-owned (OrganizationOwned).
     
    Configuration or system-related tables are often organization-owned.
     
    Example Query:
     
    GET [Organization URI]/api/data/v9.2/EntityDefinitions?$select=LogicalName,OwnershipType
     
    Filter for OwnershipType=1 (UserOwned) to target business-critical data.
     
    3. Leverage Naming Conventions
    Standard Microsoft system tables often use specific prefixes like msdyn_, mscrm_, or plugin.
     
    Custom business tables often use custom prefixes or meaningful names.
     
    Approach:
     
    Programmatically exclude tables with prefixes such as msdyn_, mscrm_, plugin, etc.
     
    4. Analyze Table Purpose through Metadata
    Use properties like Description and DisplayName in the metadata to identify table purposes.
     
    Business-critical tables often have meaningful descriptions, while system tables may have generic or technical descriptions.
     
    Example Query:
    GET [Organization URI]/api/data/v9.2/EntityDefinitions?$select=LogicalName,DisplayName,Description
     
    5. Exclude Known System Tables
    Maintain a list of known system and configuration tables (e.g., msdyn_fieldservicesystemjob, plugintracelog) to exclude programmatically.
     
    Microsoft provides a list of system tables here.
     
    6. Use the IsAuditEnabled Property
    Business-critical tables are often audit-enabled, while system tables are not.
     
    Query IsAuditEnabled to identify business-relevant tables:
     
    GET [Organization URI]/api/data/v9.2/EntityDefinitions?$select=LogicalName,IsAuditEnabled
     
    7. Manual Overrides for Edge Cases
    For any ambiguous tables, you may need a manual review or predefined rules to classify them.
     
    Example Code (C#)
     
    Here's an example using the Dynamics 365 SDK:
     
    using Microsoft.Xrm.Sdk;
    using Microsoft.Xrm.Sdk.Messages;
    using Microsoft.Xrm.Sdk.Metadata;
    using System.Linq;
     
    public void GetBusinessCriticalTables(IOrganizationService service)
    {
        // Retrieve all entity metadata
        RetrieveAllEntitiesRequest request = new RetrieveAllEntitiesRequest
        {
            EntityFilters = EntityFilters.Entity,
            RetrieveAsIfPublished = true
        };
     
        RetrieveAllEntitiesResponse response = (RetrieveAllEntitiesResponse)service.Execute(request);
     
        var businessTables = response.EntityMetadata
            .Where(e => e.IsCustomEntity == true || 
                        e.OwnershipType == OwnershipTypes.UserOwned)
            .Where(e => !e.LogicalName.StartsWith("msdyn_") && 
                        !e.LogicalName.StartsWith("plugin"))
            .Select(e => new
            {
                e.LogicalName,
                e.DisplayName,
                e.Description
            });
     
        foreach (var table in businessTables)
        {
            Console.WriteLine($"Table: {table.LogicalName}, Name: {table.DisplayName?.UserLocalizedLabel?.Label}, Description: {table.Description?.UserLocalizedLabel?.Label}");
        }
    }
     
    Summary of Key Filters
     
    1. IsCustomEntity=true
    2. OwnershipType=UserOwned (1)
    3. Exclude known system prefixes (msdyn_, plugin, etc.)
    4. Include IsAuditEnabled=true where applicable.
     
    This approach ensures you target business-critical data tables while filtering out configuration or system tables.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

December Spotlight Star - Muhammad Affan

Congratulations to a top community star!

Top 10 leaders for November!

Congratulations to our November super stars!

Tips for Writing Effective Verified Answers

Best practices for providing successful forum answers ✍️

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 291,387 Super User 2024 Season 2

#2
Martin Dráb Profile Picture

Martin Dráb 230,432 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Product updates

Dynamics 365 release plans