Using a consistent and meaningful naming convention for custom tables (entities) in Dynamics 365 is critical for long-term maintainability, collaboration, and clarity. Here are some best practices and considerations:
Best Practices for Naming Conventions
1. Use Publisher Prefixes
Dynamics 365 automatically adds a prefix (e.g., new_) to custom tables and fields based on the publisher of the solution.
Recommendation: Use a meaningful and unique prefix for the publisher that reflects either:
The customer's company name or abbreviation (e.g., abc_ for ABC Corporation).
The solution or vendor name if multiple vendors are involved (e.g., crm_ for a CRM solution provider).
This ensures a clear differentiation between custom and out-of-the-box tables.
2. Descriptive Table Names
Focus on the business purpose or function of the table rather than company/vendor branding.
Examples:
Use abc_ServiceRequest instead of abc_Table1.
Use crm_SurveyResponse instead of crm_CustomEntity.
3. Consistency in Case and Format
Use Pascal Case for table names (e.g., abc_CustomerFeedback).
Avoid spaces, special characters, or overly long names.
4. Avoid Company Names in Table Names
Including the company's name in every table (e.g., ABC_Customer) can clutter the schema and become irrelevant if the system is transferred or the company name changes.
Instead, use the publisher prefix for such purposes.
5. Prefix for Global Purpose or Shared Solutions
If a table is meant for cross-department or enterprise-wide use, use a prefix reflecting its purpose, like global_ or shared_.
6. Suffix for Functional Areas
Optionally add suffixes to group tables by function:
abc_LeadTracking
abc_InvoiceManagement
This makes it easier to identify related tables when working in the schema or ERD.
7. Avoid Redundancy
Do not repeat information in the name that is already obvious (e.g., abc_Table_CustomerTable).
8. Think Long-Term
Design names with future expansion in mind. Avoid abbreviations that may become unclear over time.
For example, avoid cryptic names like abc_LM if it stands for "Lead Management."
Common Patterns
Why Descriptive Names Are Better
Clear ERD Models: Descriptive names make the entity relationship diagram (ERD) self-explanatory.
Ease of Collaboration: Helps developers, admins, and business users quickly understand the schema.
Future-Proofing: Reduces ambiguity if the solution is modified or transferred to other vendors or teams.
Conclusion:
Use publisher prefixes for differentiation (abc_, vendor_).
Name tables based on their business purpose or function.
Avoid using company names directly in the table names.
Be consistent in naming conventions and use descriptive, long-term-friendly terms.
This approach will help ensure that your schema remains intuitive, scalable, and manageable over time.
