Dataverse Entity Naming Best Practices

(3) Share

Report

Posted on by AZWildcat1290

Hi everyone!

We are in a situation where we are rebuilding our system and trying to come up with a best practice when creating entities. We have run into issues in the past where we would create an entity and then later on install an add on from Microsoft which has the same entity name for example Time Entries which is included in Project Operations and Field Services. Has anyone come up with any best practices for their company when it comes to naming entities to avoid this situation? Duplicate entity names make it really hard when it comes to doing searches and reporting in Dynamics and Power BI. One of my team members suggested we tack on the solution name either before or after the table name. Pros and cons of doing this? Or do you have any other suggestions?

Thank you for the help!

All responses (4)

Answers (1)

Verified answer

Daivat Vartak (v-9d... 6,000 Super User 2025 Season 1 on at

Like (2)

Report
Dataverse Entity Naming Best Practices

Hello AZWildcat1290,

You've identified a common and frustrating challenge in Dynamics 365: naming collisions, especially when installing multiple Microsoft solutions or third-party add-ons. You're right to be proactive about establishing best practices.

Understanding the Problem:

Namespace Collisions: Dynamics 365, like many platforms, operates within a namespace. When multiple solutions introduce entities with the same logical name, it creates ambiguity and potential conflicts.

Reporting and Integration Challenges: Duplicate entity names make it difficult to:

Write clear and unambiguous queries.

Create reports that accurately represent the data.

Integrate with other systems like Power BI.

Proposed Solution: Prefixes/Suffixes with Solution Names
Your team member's suggestion of using prefixes or suffixes with solution names is a common and generally good approach. Let's weigh the pros and cons:
Pros:

Uniqueness: It significantly reduces the risk of naming collisions.

Clarity: It makes it easy to identify the source of an entity.

Organization: It helps organize entities within your environment.

Improved Reporting: It simplifies reporting by providing clear distinctions between entities.

Cons:

Verbosity: Entity names can become longer and less readable.

Maintenance: You'll need to establish and maintain a consistent naming convention.

Potential for Length Limits: Dynamics 365 has limitations on the length of entity logical names.

Best Practices and Recommendations:

Consistent Prefixing (Recommended):

Using prefixes is generally preferred over suffixes because it groups related entities together alphabetically.

For example:

projop_TimeEntry (Project Operations Time Entry)

fieldserv_TimeEntry (Field Service Time Entry)

This approach keeps related entities grouped when browsing lists and makes it easier to write queries.

Abbreviate Solution Names (Carefully):

To mitigate verbosity, you can abbreviate solution names, but do so consistently and document the abbreviations.

For example:

po_TimeEntry (Project Operations)

fs_TimeEntry (Field Service)

Establish a Naming Convention:

Create a document that outlines your organization's entity naming convention.

Include:

The format for prefixes/suffixes.

Abbreviations for common solutions.

Guidelines for naming custom entities.

Make this document readily available to all developers and administrators.

Consider Namespaces (If Possible):

While Dynamics 365 doesn't have explicit namespaces like some programming languages, you can simulate them using prefixes.

Use Display Names for User Friendliness:

Remember that the logical name is primarily for system use.

Use clear and user-friendly display names for entities and fields.

For example:

Logical Name: po_TimeEntry

Display Name: "Project Operations Time Entry"

Avoid Generic Names:

Avoid using generic entity names like "Data" or "Record."

Be as specific as possible.

Document Customizations:

Thoroughly document all custom entities and fields, including their purpose and any naming conventions used.

Power Platform Solutions:

When creating your own solutions, use a unique prefix for all entities within that solution. This will help to keep your solutions organized, and to help to prevent naming collisions.

Additional Considerations:

Existing Entities: If you already have existing entities without prefixes/suffixes, you might need to consider renaming them (with caution, as this can affect existing integrations).

Third-Party Solutions: When installing third-party solutions, carefully review their entity names and consider renaming them if necessary.

By implementing a consistent and well-documented naming convention, you can significantly reduce the risk of naming collisions and improve the maintainability of your Dynamics 365 environment.

If my answer was helpful, please click Like, and if it solved your problem, please mark it as verified to help other community members find more.
If you have further questions, please feel free to contact me.

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

Regards,
Daivat Vartak
CU24030205-0 2 on at

Like (0)

Report
Dataverse Entity Naming Best Practices

When creating entities in Dynamics 365, you can use the Publisher Prefix and raft wars configured in your solution. This helps Dynamics automatically add a unique prefix.

Advantages:

Microsoft recommends this approach and Dynamics will automatically manage it.

Optimized for queries and integration with Power Platform.

Less risk of conflicts with system entities.

Cons:

Cannot be as deeply customized per solution as the first option.

Without proper naming conventions, it can be difficult to tell which solution an entity belongs to.
AZWildcat1290 53 on at

Like (0)

Report

Dataverse Entity Naming Best Practices

Hi,

To update this post as I got more information yesterday the ask is more of is there a way to show the name field vs the display name to the backend users no matter what system they are using ie running reports, flow, powerbi? Or is it possible to have a custom display name where we can set it to the Display Name with an * at the end for example Time Entry*. We dont necessarily want end users to see the * but for the backend users it would be super helpful to know which fields are custom...

Thanks!

Stephanie
Suggested answer

Dengliang Li Microsoft Employee on at

Like (0)

Report

Entity Naming Best Practices

Hi,

When creating a custom entity, the logical name is automatically prefixed with the solution. However, the display name can be repeated.

Yes, you can add a custom prefix to the display name of an entity.
If you have two custom entities with the same display name, you can add a prefix based on their specific purpose to make the name clearer.

Best Regards,
Dengliang Li