The primary goal of any business management software is to collect data to speed up processes and to generate reliable reports (such as revenue forecasts). With a poorly built CRM, “bad data” is a common complaint: management teams request a “simple report”, but when the data is “bad”, there is not much that a developer can do to generate the report.
This problem can be eliminated by proper field and entity definitions. A great CRM system has field types defined to guide the user to enter the correct data type, which can lead to robust and colorful reporting.
Planning and defining the business process can make or break a CRM or Dynamics 365 deployment. Do I need to plan each field? Not necessarily, but you will need to define how your data relates to itself. How does the Account entity relate to the Opportunity entity? How does the Contact entity relate to the Claims entity?
Here, we will walk through an example of an entity and fields based on a medical insurance example.
What are the Fields? What are the Entities?
Entities and their Fields are the foundation of Dynamics 365. As a visual example, you can think of Entities like a table in Excel, and Fields are each column. Dynamics 365 removes the rigidity of the tabular appearance by giving users a very appealing interface, but at its core, Dynamics 365 is a very sophisticated set of tables with lots of columns.
Just like in Excel, if you want to generate a meaningful chart or pivot table, you need to ensure that the data entered in the column is the correct type by restricting the column to be a number, or a date, or even a currency. The same principle applies to Dynamics 365. In order to generate meaningful charts and reports, you need to restrict the data entry to make sense.
Scenario: Claims Entity
You work at a medical insurance provider. You are a business analyst who has been recruited to assist the system administrator with defining the structure of a new Dynamics 365 deployment. Where do you start? How do you tackle translating the current process into “Dynamics 365 Lingo”?
This is a huge task, so we are going to boil this down to one area: claims. After multiple discussions with the claims processing team, where they detailed their day-to-day process, and with senior management, where they provided current reports and desired future reports, you are ready to plan out this section of the solution.
At a high level, the claims processing team needs to know which claims are assigned to them, the priority level for processing, who the contact is, and document processing which is dependent on medical service type. Senior management wants to know how long a claim is in each stage of the process, broken down by claims representative and by medical service type.
Disclaimer: With any Dynamics 365 deployment, there are multiple ways to accomplish the same goals. Here, we will walk through creating a claims entity and adding the relevant fields for the claims processing team. However, another valid approach would be to repurpose the out-of-the-box Claims entity and rename/customize it to become the Claims entity. There are many other things to consider when planning your structure (security privileges, automation, end-user experience, etc.); this is simply an illustration.
Step 1: Create Claims Entity
From the Components area within the solution, click New Entity. Enter information for Display Name, Plural Name, Name, and Ownership in order to save (note: these are Business Required, so it’s mandatory to fill them out and save them).
Since the claims processing team has ownership of a Claim, the Ownership needs to be set to User or Team. This is something you cannot change after creating the entity. The other option is the Organization, which means no user has ownership of the record (example: Competitor Entity).
Besides the entity definition, there are seven sections to fill out when creating an Entity: Areas that display this entity, Options for Entity, Process, Communication & Collaboration, Data Service, Outlook & Mobile, and Help.
- Areas that display this entity: where on the Sitemap does this entity show up? This can be changed after entity creation.
- Options for Entity: is this entity enabled for an interactive experience?
- Process: is this entity enabled for Business Process Flows? This cannot be changed once selected and saved as yes, since fields related to tracking the stage is created.
- Communication & Collaboration: This is a very large section that contains options like Activities, Mail merge, OneNote Integration, and Queues. Most of these options cannot be changed once saved as yes.
- Data Service: This section is critical. Will this entity be enabled for auditing? Duplicate detection?
- Outlook & Mobile: can this entity be available in the Dynamics 365 Mobile App? Is it available from within Outlook? These can be updated at any time.
- Help: will this entity have a custom help link?
Here, we will keep it simple. This is a claims entity that is owned by a user or team, available within Service, with Activities and Notes, that is audited.
Step 2: Edit Form and Add Fields
Once the entity is created, there are two ways to add more fields. The first is under Fields within the Claim entity. The second (and probably more intuitive) method is through the Field Explorer on the form you want to edit.
Option 1
Option 2
Going back to the requirements…
At a high level, the claims processing team needs to know (1) which claims are assigned to them, (2) the priority level for processing, (3) who the contact is, and (4) document processing.
- Ownership field is automatically created when we selected the user or team when we created the Claims entity — Status = Done!
- Priority Level field needs to be created, and it needs to be an Option Set with High, Normal, and Low as the options. Imagine the chaos that would occur if this field was a single line and you needed to pull all the High Priority Claims.
- Pro-tip #1: Do not overlook Use Existing Option Set – 90% of the time (or more) you will want to change this value to Yes. This enables you to use the same option set values across multiple entities and workflows.
- Pro-tip #2: Change the Name of the field to end in “code” for option sets. Example: Display Name = Priority Level, Name = hsdyn_prioritylevelcode. This gives developers some insight into the field type.
- Contact field needs to be created. This needs to be a Lookup field – it needs to look to the Contact entity and establish a connection. Connecting the Contact entity and the Claims entity through a 1:N relationship will let you answer the question “how many claims has this person submitted over the past X months?”
- Pro-tip: Change the Name of the field to end in “id” for lookups. Example: Display Name = Contact, Name = hsdyn_contactid.
- Document processing has many possible options, but a natural choice is a two-option field to track if documents have been processed, or if documents have not been processed yet. Since this is asking a question, set up the Display Name to read “Document Processing Complete?” with options Yes or No, with No as the default.
- Pro-tip: Change the Name of the field to start with “is” for bit fields. Example: Display Name = Document Processing Complete?, Name = hsdyn_isdocumentprocessingcomplete.
After adding these fields and updating the form layout, here is the end result:
Bonus Tip
Dynamics 365 lets you update the entity icons from the solution.
Previously, you needed to use XrmToolBox or other developer tools to add 16×16 and 32×32 images, but now you can easily add icons to custom entities using the Update Icons button.
Customer Fields – New Data Type
Dynamics 365 has 12 data types available: Single Line of Text, Option Set, Two Options, Image, Whole Number, Floating Point Number, Decimal Number, Currency, Multiple Lines of Text, Date and Time, Lookup, and a new Dynamics 365 Data Type called Customer.
This data type has been available on out-of-the-box entities such as Opportunity, but Dynamics 365 now allows you to create your own on custom entities. In our example above, if the requirement had said “to know the contact or the account associated with the claim”, then a Customer field would have been a natural choice.
Awesome! How Do I Get Started?
If you are starting off a project and are planning out your CRM system, make sure to meet with subject matter experts to explore their day-to-day process. It is also critical to analyze the current data – this will help guide you to natural data type choices.
For example, if you are currently using Excel, some users might enter “Y” and “N” while others use “Yes” and “No”; and some might even use “Maybe”. Understanding what the data currently is will help you build out an appropriate solution, and will give you a head-start with data mapping and migration efforts.
Srinath Pega 