Customer experience | Sales, Customer Insights,...

Answered

Custom Table Names

(1) Share

Report

Posted on by Testmermaid

Hi All,

Is there a best practice for naming convention in Dynamics for custom tables? I see some vendors use their name as a prefix and others use a descriptive prefix to a custom table while still others use the prefix of the customer's company name.

I would think in the DB model is always best to utilize descriptive function/purpose/business names that are useful in the ERD, not necessarily marking company names...thoughts?

Thanks in advance!

Categories:

Microsoft Dynamics CRM

All responses (5)

Answers (1)

Suggested answer

Amit Katariya007 9,150 Super User 2024 Season 1 on at

Like (2)

Report

Custom Table Names

It is common practice to identify the components that created by a vendor or imported a 3rd party solution to an environment.

It will help a developer to identify all the components that created by the vendor as well as the current organisation.

This will make sure to provide a hint about components when we have common entities like Account, contact, lead, case, etc.
Verified answer

Testmermaid 14 on at

Like (0)

Report

Custom Table Names

Respectfully, For whomever may read this post going forward.

It is not common, nor acceptable, nor beneficial to include the company name in the Database table names. It is quite unnecessary and other than taking ownership or marking a territory I cannot think of a reasonable reason to do so. It adds to the table length unnecessarily and does not add a beneficial descriptor to development, DB administrators or business users for that matter.
Suggested answer

Amit Katariya007 9,150 Super User 2024 Season 1 on at

Like (2)

Report

Custom Table Names

For more details please follow below article.

Entity naming conventions best practices
Suggested answer

Amit Katariya007 9,150 Super User 2024 Season 1 on at

Like (2)

Report

Custom Table Names

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.
Suggested answer

Saif Ali Sabri 381 on at

Like (0)

Report
Custom Table Names

My response was crafted with AI assistance, tailored to provide detailed and actionable guidance for your query.

In Microsoft Dynamics 365 Business Central and Finance & Operations, adopting a clear and consistent naming convention for custom tables (and other objects) is crucial for maintainability, clarity, and collaboration.

1. Use a Unique Prefix for All Custom Objects

Microsoft strongly recommends using a unique prefix for all custom objects (tables, pages, codeunits, etc.) to avoid naming conflicts with standard objects, ISV solutions, or future platform updates.

Best Practices for Prefixes:

Vendor or Partner Prefix: Use your company or vendor name as the prefix if you are building reusable ISV solutions or apps for AppSource. Example: MYCOMP_CustomerData.

Example: A company "MyCompany" might prefix all objects with MYCOMP_.

Descriptive or Functional Prefix: Use a prefix that describes the functionality of the table, especially for customizations tied to a specific purpose or business process.

Example: HRM_EmployeeHistory (for an HR module) or CRM_CustomerEngagement.

Customer-Specific Prefix: Use the customer’s name or abbreviation as a prefix for objects created specifically for their implementation, especially if the customizations are not intended for reuse in other projects.

Example: FAB_CustomerPortal for a client "Fabricam".

However, avoid overly generic prefixes like CUST_ or CUSTOM_, as they don't clearly identify the origin or purpose of the object.

Key Recommendation: Use a prefix that balances uniqueness and descriptive purpose. Avoid hardcoding customer names into objects unless the object is highly specific to that customer.

2. Descriptive, Purpose-Oriented Names

Beyond prefixes, table names should clearly describe the purpose or functionality of the table. This improves readability in the database schema, ERD, or AL code.

Examples:

Instead of MYCOMP_Table1, use something descriptive like MYCOMP_ProjectBudget.

Avoid abbreviations that are not commonly understood unless they are standard in the industry.

Benefits:

A descriptive name helps developers, consultants, and business users understand the table's purpose at a glance.

It supports collaboration across teams and documentation.

3. Avoid Including Customer Names Unless Absolutely Necessary

While some vendors use customer names in table names (e.g., FAB_CustomData), this is generally discouraged unless:

The object is specifically tied to that customer and not reusable.

There’s no intention to generalize the table for future implementations.

Using functional or purpose-oriented naming is more scalable and avoids cluttering your naming convention with customer-specific information.

4. Follow Microsoft Naming Guidelines

Microsoft provides specific naming guidelines for custom tables in Business Central and Finance & Operations:

Table Object ID Range: Use a valid object ID from your assigned range. For extensions, object IDs typically start from 50,000.

Avoid Reserved Words: Ensure the table name doesn’t conflict with reserved words or standard object names.

Camel Case or Pascal Case: Use CamelCase or PascalCase consistently for readability.

Example:

MYCOMP_OrderTracking (Prefix + Descriptive Name)

5. ERD and Business-Readable Models

For database models and ERDs:

Use descriptive names that are easy to understand for both technical and business users.

Prefixes (e.g., MYCOMP_) can be kept concise in ERDs to avoid clutter.

Use business terminology whenever possible to bridge the gap between technical and non-technical stakeholders.

Example:

Instead of MYCOMP_TableA, use MYCOMP_InvoicePaymentTracking.

6. Consider Future Scalability

If the custom solution has the potential to grow or be reused:

Avoid hardcoding customer names or one-off prefixes.

Focus on modular, reusable naming conventions.

Prefixes should reflect the origin (e.g., vendor or ISV) but allow room for extension.

7. Document Your Naming Convention

Clearly document your chosen naming convention as part of your project or organization's development guidelines. This ensures that all team members and future developers follow the same rules.

Summary Recommendation

Use a unique prefix (vendor, ISV, or functional) for all custom tables and objects.

Focus on descriptive, purpose-oriented names that explain the table's business function.

Avoid hardcoding customer names unless the customization is explicitly customer-specific.

Follow Microsoft guidelines for consistency.

Prioritize clarity and scalability for both technical and non-technical users.

By following these guidelines, you’ll create a robust, maintainable, and scalable database model that aligns with Dynamics 365 best practices.

Custom Table Names

1. Use a Unique Prefix for All Custom Objects

Best Practices for Prefixes:

Key Recommendation: Use a prefix that balances uniqueness and descriptive purpose. Avoid hardcoding customer names into objects unless the object is highly specific to that customer.

2. Descriptive, Purpose-Oriented Names

Examples:

Benefits:

3. Avoid Including Customer Names Unless Absolutely Necessary

4. Follow Microsoft Naming Guidelines

Example:

5. ERD and Business-Readable Models

Example:

6. Consider Future Scalability

7. Document Your Naming Convention

Summary Recommendation

Helpful resources

Quick Links

Congratulations 2024 Spotlight Honorees

Meet the Top 10 leaders for December

Start Your Super User Journey

Leaderboard

Featured topics

Product updates

Custom Table Names

1. Use a Unique Prefix for All Custom Objects

Best Practices for Prefixes:

Key Recommendation: Use a prefix that balances uniqueness and descriptive purpose. Avoid hardcoding customer names into objects unless the object is highly specific to that customer.

2. Descriptive, Purpose-Oriented Names

Examples:

Benefits:

3. Avoid Including Customer Names Unless Absolutely Necessary

4. Follow Microsoft Naming Guidelines

Example:

5. ERD and Business-Readable Models

Example:

6. Consider Future Scalability

7. Document Your Naming Convention

Summary Recommendation

Helpful resources

Quick Links

Congratulations 2024 Spotlight Honorees

Meet the Top 10 leaders for December

Start Your Super User Journey

Subscribe to this forum!

Select categories

Leaderboard

Featured topics

Product updates