We are obsessed with lists, and lists are everywhere in our lives. Whether we are managing email, shopping for groceries, or finding the next movie to watch, we are viewing lists. We can find a list for almost anything. We can find the best places to live, the states with the best BBQ, regions in the world with the most rainfall, or the best sporting events. We can even find lists of lists.
Dynamics 365 Portals also have lists; they are called Entity Lists, and they are a great method to display a list of records to your Portal users. You can easily and quickly create a Dynamics 365 View, Entity List, and Web Page to present the necessary data for simple needs. You have options to get quite complex if needed.
This blog is Part A of a three-part series on this subject. I’m not going to compete with existing documentation, but I will highlight some items, features, and hidden realities that are, sometimes, not clearly identified. This blog will cover the following:
- Dynamics 365 Entity
- Dynamics 365 View
- Multiple Views
- Display Name
- Page Size
- Web Page for Details
- Web Page for Create
- Filter Conditions
- What You Need to Know Right Now
Dynamics 365 Entity
Components of Contact entity as seen in the default solution:
A common dictionary definition for entity is “a thing with distinct and independent existence.” At the beginning of my programming days, the instructors repeatedly stressed that each object had its own properties and methods. Properties and methods, properties and methods, and don’t forget properties and methods. They are what make up an independent object, an item unique from surrounding objects.
Considering D365 (Dynamics 365) CE and D365 Portals, an Entity is a container of information about a single object, whether it is a Lead, an Account, a Contact, an Opportunity, an Activity, etc.
When designing a D365 CRM system or a D365 Portal website, this philosophy also holds true. We need to clearly identify each entity or object to determine how it looks and behaves in order to create a system that doesn’t stumble upon itself. I encourage clients to ask this vital question when planning or developing D365 entities, “who owns the data?” Go ahead and ask it; you’ll feel better and maybe even a little powerful. What do I mean by this?
Using Accounts and Contacts as my illustration, let’s focus on the Account address. Many times, clients want to place the Account address, physical or billing, on the Contact entity, and that’s fine – on the Contact form, but it doesn’t belong on the Contact entity. When considering the actual data model design, it’s the Account that owns the address, not the Contact. The Contact may work at that address, but it’s not theirs. So, who owns this address? When I drive to that location, I will see the business site, not a person’s house.
Here is how a system can fall down if not designed properly. A D365 User changes the address only on the Contact form, but the Account address is also on the Account form. Another user logs into the system to get the Account address and navigates to the Account record. They are looking at the wrong address! Unless a synchronization process is in place, incorrect data will abound. For this particular scenario, it would be better to display an Account Quick View Form on the Contact form.
So, what do entities and objects, properties and methods have to do with Entity Lists and D365 Portals? Understanding these concepts will assist in your Entity List development and recognize their abilities and limitations.
Dynamics 365 View
A D365 Entity List is simply an extension of a D365 View. A View is an organized list of specified data about one or more entities.
Here is a D365 View Editor:
From this editor, you add and remove columns, change the width of columns, dictate the default sort order of the list, and determine the filtering conditions.
Display of View in D365 CE:
To associate an Entity List to a D365 View, follow these instructions.
Navigate to the Portals Area in D365 and select Entity Lists.
Select + New.
It may take a bit before the Entity Name field list populates; this is common with Portal entity records – a word of warning.
Select the desired entity “object” for Entity Name field.
Next, click + View and a new View section will appear in the Views area.
Select the desired D365 View in the Name list.
After creating a Web Page and pointing it to the Entity List, navigate to your D365 Portal.
D365 Portal Representation of the D365 View:
Multiple Views for One Entity List
The above View is nice, but how do we handle a situation if multiple Views need to be displayed to the D365 Portal user? First of all, let’s review why we would need to do this. You may have a desire to display all active Contacts like above, but you may also want to display all active Contacts that have been created or modified in the last 90 days, a much smaller list that also identifies CreatedBy, CreatedOn, ModifiedBy, and ModifiedOn and is sorted by most recent on top.
In D365 CE, create your View, ensuring you add your filtering criteria, Save, and Publish All Customizations. If you already have your Entity List record open, you will have to click Refresh View in the Views area.
Click + View and select your new View. Save.
Navigate to your D365 Portal Web Page and refresh.
Now you will see a View selector: Active Contacts and Active Contacts – Created or Modified in Last 90 Days. Select the new view.
Now that we have two views in our Entity List, the naming of the Views may not make sense to the Portal users. Display name mainly comes into play when there are multiple Views added for one Entity List.
Navigate back to the Entity List and add your values (Contacts; Recent Contacts) to the Display Names. Save.
Multiple Views with better naming for your Portal Users
Did you notice this above on the main Contact list in Portals?
This is a common paging system for a list of records. We have the ability to change the Page Size for every Entity List.
When it comes to Page Size, paging, and performance, there is a fine balance. You may need to test this and request user feedback, but I feel 50 is a good starting number for Portals. After changing the Page Size from 10 to 50, and without showing the entire first page of results, you can see below the number of Pages are quite a bit less. Page Size in combination with Filter Results and Search (covered later) gives you the benefit of showing the least amount of records to increase performance and provide the Portal user the functionality to quickly find the records they need.
Web Page for Details View and ID Query String Parameter Name
Many times your company will want Portal users to create and modify data.
In the Entity List record, assign a Web Page – that is already created and pointed to an Entity Form or Web Form – to the Web Page for Details View field. Enter a name for the value of the parameter that will be passed from the Entity List to the Details View Web Page. The default naming for this field is “id.” Save and refresh the Entity List Web Page.
When the Portal user clicks on Abraham’s record on the Entity List Web Page, the Portal will navigate to the Contact – Edit Web Page, sending the Contact Id value as a parameter. The Contact – Edit page will pick up that Id parameter, retrieve the necessary data, and populate the edit form.
The receiving Web Page could be an edit form, read-only form, or a custom Web Page.
Web Page for Create
If Portal users also need to create a new record of the same type as the Entity List, create the Entity Form or Web Form and the corresponding Web Page, and then enter into the Web Page for Create field.
Entity List Web Page with Create button
Create form Web Page
Interestingly, this has the same effect as the Grid Configuration redirecting to a Web Page with a Create View Action.
We have the option to further limit the results of the D365 View; we don’t have a lot of choices, but they pack a powerful dynamic punch. In the Filter Conditions section on the Entity List record, I will discuss the first two: Portal User Attribute and Account Attribute.
I’m a database guy – got my feet wet many years ago with MS Access, dabbled a touch with DB2, spent over a decade with Oracle, explored MySQL, and have been working with SQL Server for quite some time now. I speak SQL. Sometimes I want to write SQL statements to my family, things like:
WHERE stuff IN (‘Your Shoes’, ‘Your Toys’, ‘Your Clothes’);
I’m sure they would throw me an exception!
To instruct on how to think about Entity List Filter Conditions, I will speak SQL.
No Filter Conditions
When no Filter Conditions are entered, you are basically requesting this:
WHERE conditions = D365 View filter conditions;
You are not adding onto the D365 View filter conditions, and you will receive the same results from the Portal as you would in D365.
Portal User Attribute
Here are the Portal User Attribute options for the Contact Entity List.
If all Contact/User fields were exposed on the Contact form, you would see these fields above. We will select Parent Contact as the filter condition for the Contact Entity List.
And here is the vital understanding for Entity List Filter Conditions: filtering the Entity List is filtering by lookup fields on the Entity form with either a Contact/User or Account value. For this example, we are filtering by Contact Id.
In other words, you are requesting this:
WHERE ParentCustomerId = PortalUser.ContactId
AND conditions = D365 View filter conditions;
As you know, a Customer field – in this case Parent Customer – is either an Account or Contact, so this statement is saying, “Give me all Contacts where the Parent Customer (Parent Contact) lookup field is equal to the Portal User that is logged in.”
I’m logged in as me, Gary Harrison, and I happen to be the Parent Customer, or Parent Contact, to several records, one of them being Amie Gonzales.
Results of ParentContactId Filter Condition
The same concept and process applies to the Account Attribute, but it refers to the Account field.
Here are the Account Attribute options for the Contact Entity List.
Select Company Name (Parent Customer Id) for the Account Attribute on the Contact Entity List record.
Fabrikam Robotics is the Company Name on my record.
Here, we are requesting this:
WHERE ParentCustomerId (AccountId) = PortalUser.ParentCustomerId (AccountId)
AND conditions = D365 View filter conditions;
This statement is saying, “Give me all Contacts where the Company Name lookup is equal to the Company Name lookup for the Portal User that is logged in.”
Results of ParentCustomerId Filter Condition
If you are excited about this capability and want to filter by more than just Contact, User, and Account, read this blog by ReadyXRM.
What You Need to Know Right Now
We have covered a lot of ground in just Part A of the Entity List series, but this is what you need to know right now about Entity Lists:
- Entity List is tied to only one D365 entity
- You can display parent fields in the Entity List
- Multiple views can be displayed for one Entity List
- All Views for Entity List are visible and available for each logged-in User with appropriate permissions unless dynamically altered
- You cannot hide one of the Views for a certain set of Portal Users
- All Views for Entity List point to the same Edit page, the same Create Page, and have the same grid configurations
- All Views for Entity List share the same Filter Conditions
- Meaning you cannot direct a certain set of Portal Users to one page and another set of Portal Users to a different page with the same link
- If you Enable Entity Permissions on the Entity List, Portal Users must be added to that Entity’s Entity Permissions
- If not, no results will no display
- Portal Users cannot sort on parent fields
Dynamics 365 CE (CRM) How-To eGuide
41 pages of step-by-step instructions for 6 different key tasks in Dynamics 365 Customer Engagement (CRM). Includes interactions with PowerApps and Flow!Get the eGuide