Recently a customer had a requirement to show the active stage of the business process flow on an entity (table) view. Whereas I initially thought this would be a rather simple requirement, there were some challenges in order to achieve the required functionality. In this blog post I will explain the steps for creating such an “advanced” model driven app view.
Business process flow data model
First, a bit of history with regards to the business process flow component. Since Dynamics 365 v8.2, the business process flows are modeled as a “backing” entities. This allowed the ability to manage multiple business process flows on a single record. As a result, the fields Stage Id & Traversed Path on the record, no longer made sense (and were deprecated). The relationship between your entity and the business process flow entity is modeled as one-to-many.
Capabilities of the out of the box view editor
The out of the box view editor has greatly improved throughout the years. I remember those days where we had to save and publish each time to see the actual impact of a change. Make the column just a bit wider, save and publish again, etc. Today, this has changed an each modification is instantly visible (a true WYSIWYG).
The view editor is supporting many-to-one relationships using the related tab. This allows you to select fields from the related lookup entity. Refer to the example below.
Multiple one-to-many levels deep is not supported. Also, many-to-many or one-to-many relationships are not possible using the out of the box view editor. Are these limits platform limits or UI editor limits?
FetchXML and LayoutXML of a view
A model driven app view is defined based on certain properties, where FetchXML and LayoutXML are the two most important ones. The FetchXML basically defines the data query of the view (e.g. “My active acccounts”) & the LayoutXML defines how the view should look like (e.g. Showing the Status & the Name columns with a certain width). Surely we could query the necessary data using a FetchXML (join), but can we also show the result in the view by manipulating the LayoutXML? Yes, we can! 🙌
XrmToolbox View Designer
Manipulating the FetchXML and LayoutXML of a view could be done by using the API, by customizing the solution XML or by using the XrmToolbox (most lazy way). Choice quickly made 😇. Credits go to Innofactor AB for creation of the View Designer XrmToolbox plugin.
After installing the tool (I skip theses steps), the first step would be to open the specific view that you want to enhance.
Next, you want to edit the underling FetchXML. That can be done with the help of the FetchXML Builder (thanks Jonas Rapp). Clicking on “Edit Query” would take us right to it.
Build and validate your query. In below example I am performing an inner join from my alx_referencecase entity to my business process flow entity and finally to the stages entity to get the stage name field (so multiple many-to-one levels deep).
Important: Make sure your all your linked entities have an alias set! This alias will be used as name in your column view. Do NOT set an alias on your attribute (this will not work).
Return your FetchXML to the View Designer by the click of a button.
Final step would be to add the column to the view (LayoutXML). Do this by clicking “Select Columns” and selecting the new column that shows up. In my case, this was stage.stagename.
Note: The live preview feature of the View Designer does not seem to surface the correct data. Don’t worry, we have to click save and publish to see our change in the model driven app.
After hitting save and publish, refresh your model driven app to see the change reflected.
After the view has been enhanced, you can still go back to your familiar view editor to make further adjustments (e.g. changing the width or position of the column).
Conclusion
The out-of-the-box view designer does not allow the ability to configure more advanced scenarios. The framework however uses FetchXML and LayoutXML to define views and more advanced scenarios are actually possible. Using the help of community tools, we can (relatively) easily create more advanced views. This opens up quite some possibilities.
UPDATE 07/02/2021: These “advanced” views seem to have broken the Export to Excel & the Chart designer. So, use this with caution!
Hey, this is awesome! Not only did I learn how to do this but I also got to know a great tool (XrmToolBox).
Unfortunately, I ran up against the same excel export situation that you highlighted in your final comment. Is there no other way around this?
I’m also unsure as to how to go about changing the column header so that it shows something else other than stage.stagename.