Blog

Dynamics 365 Form Notifications

Microsoft Dynamics 365 Entity Best Practices

This is the fourth blog in my 12 part series focusing on Microsoft Dynamics 365 Best Practices. If you’ve missed my previous blogs, they’ve focused on defining Best Practices, Organizations, and Solutions and Patches. For my remaining blogs, I’m going to focus on the different components in Dynamics 365, starting with Entities.

What is an Entity?

Dynamics 365 comes with several out of the box entities. One of the great things about Dynamics 365, is that you can build upon those entities and even create your own custom entities. You can even relate custom entities to the out-of-box entities.

An entity represents a table in the underlying database. Accounts, Contacts, Leads, Opportunities, and Cases are all examples of system entities. As you evolve your system, you may find the need to create new entities. You may also find the need to create relationships between different entities as well. Great news! Dynamics 365 can handle this.

Where to Start

While Dynamics 365 can handle a lot of custom entities, there is a limit. If you hit your limit then you will have to contact Microsoft’s technical support. In all my years working with Dynamics 365, I have not seen anyone hit the limit yet.

Before firing at will and creating custom entities for every little nuance you come across, think. Always take into consideration your standard entities before creating a custom entity. Don’t forget about activity entities as well. Once I saw where a simple Type field on the Task Activity would have alleviated the need for over five custom entities. Remember that you can export Translations to quickly rename entities as well. There isn’t as great of a need for the Letter and Fax activity types any longer. You can rename these entities to something more suited to your needs without having to create a custom activity entity.

Keeping it Organized

In my previous blog, I talked about creating a publisher and a prefix. I also talked about creating a base solution and using patches. You’ll want to create any new entities in your solution or in a patch to ensure that it inherits your publisher’s prefix. If you create a new custom entity for Account Categories, you’ll want the entity name to be abc_category rather than the system default of new_category.

When creating a new entity, once you hit Save, you can’t change the primary field name or the ownership type. These are things that you’ll want to consider while you’re setting up your entity. Also, the primary field must always be a text field. You can change the requirement level, but you cannot change the type. When creating entities that will be used as “option sets” on a form, you almost always want to make these organizational owned. An exception to this would be if your organization has strict Business Units where data is kept in silos and the records in the new entity must only be seen by one Business Unit.

Making it Visible

In a future blog, I’ll talk more about best practices surrounding security, but I’m going to touch on it a little bit here. Many times after creating a new entity and testing it as a system administrator, we forget to change the users’ security roles. If you have a lot of security roles and you want all users to see your new entity, you’re going to have a lot of updates to make. One of the best practices surrounding security is to implement a layered approach. With a layered approach, you can have a Base Role that ALL users have. When you add custom entities, you can add the security privileges to the base role. This works perfectly when all users should have the same security access. If the access varies, then you’ll have to update individual roles.

If you’re using the new UI, which I highly recommend that you do, you’ll also have to add your new entity to the App. Have fun with your new entity and find an icon that you can apply to it. You’ll want to use an svg image with the UI rather than an ico image.

What Next?

It’s time for you to start creating new entities! Dynamics 365 is a great system because it can be easily expanded to meet YOUR business needs. You don’t have to adapt your processes to meet system limitations. Be sure to follow the above best practices so that your users don’t get frustrated. Also, so that your system administrators can easily step in for each other without a lot of questions. If everyone is playing by the same set of rules, then you’ll never wonder what something is or why is was done that way.

Contact Us!

Please contact us today if you have questions about Dynamics 365 Best Practices or if you have a topic or certain Dynamics 365 component that you are particularly interested in hearing about in regards to its Best Practices.

Beringer Technology Group, a leading Microsoft Gold Certified Partner specializing in Microsoft Dynamics 365, CRM for Distribution, Office 365,  Managed IT ServicesBackup and Disaster RecoveryCloud and Unified Communication Solutions.