If you have a standard-size flat or home, you probably only have one kitchen - just like me. But when it comes to cooking our model-driven apps, we are spoiled for choice as we have 2 experiences to choose from!
The first is the “classic interface” kitchen – a bit dated, but with emotional sentiment for someone like me who started working with D365 a few years back when Power Platform did not even exist yet. The second one is the modern app designer accessible via make.powerapps.com
Although they have different look & feel, navigation and overall UX, they both can be used to cook some amazing model-driven apps. However, these are not the only differences. Are you aware that some of the available ingredients can be accessed using only one of the “kitchens” and are not available in the other one?
When I am thinking about possible creators of model-driven apps, I can categorise them as follows:
Power Platform evolutionists – anyone who learnt model-driven apps via the modern app designer and might have limited or no knowledge of the classic interface.
D365 traditionalists who are not ready to “upgrade” themselves to the modern experience and still use the classic interface only. (I hope that group is very small or doesn’t exist at all!)
Embracers of both – anyone who joined after the Power Platform revolution started, but still carefully went through the classic interface and knows how to embrace both.
Upgraded “traditionalists” who started during the D365 era, but now they use the modern interface and only refer to the classic one when they need to.
“Traditionalist” in waiting – those who know the modern app designer but are still using the classic one till it is completely retired.
Do you think that reflects the reality or am I wrong about it? Also, there might be some mix of the above, but I think these 5 cover the main categories.
So, one would ask what these groups have to do with the differences between the app-building interfaces. The thing is that some of the features and components are only available via either the “classic interface” or the “modern app designer”.
Therefore, if you are in one of the groups that only uses the single kitchen instead of fully benefiting from both, you might be missing out on some of the great ingredients that could add some extra flavours to your model-driven apps.
Also, some legacy features do not seem to be doing anything when configured via the classic interface and they were not introduced to the modern app designer. Do you know any examples?
In the blog post below, I would like to cover some of them that are available through one interface, but not the other.
Classic Interface
Let’s start with what we had first, the classic “classic interface". The below list covers some of the features and components that are currently not available yet via the modern app designer, i.e. make.powerapps.com.
Mappings
Field Mappings feature is only accessible via the classic interface. This feature enables to map attributes between entities that have an entity relationship. This allows to set default values for a record that is created in the context of another record. For example, when creating a new Contact or Case records from a subgrid on an Account record, the mapped fields like the default number or address will be pre-populated.
As you know, the same results can be achieved by automation like workflow or Power Automate. However, if the mapped fields are on the form, they can be updated (if needed) before the new record is saved.
There are a few things to remember when creating Mappings:
Field types must match. The data type in the Source field needs to be the same as the data type in the Target field. For example, if the data from the field in your parent record is a “Lookup” or “Option Set”, the mapping is only possible to the same data type field for the corresponding field in the child record.
For the text fields, the target field length should not exceed the source field length.
Field mapping is just copying data on a new record creation. There is no synchronisation between the records – if that is a requirement, custom automation like workflow or Power Automate flow needs to be used.
Related entities tab
Each of the forms in the model-driven app will automatically show a “Related “ tab next to the other tabs on the form. Under the Related tab, there is a list of related entities as shown below.
The order and what exactly is shown on the list can be controlled. However, it can only be done via the classic interface. Once you open the form you would like to change, click on “Navigation” under the Home tab. Additional entities can be added via the “Relationship Explorer” (right panel). Also, the entities' order can be changed by moving them up and down on the panel on the left (shown below).
Entity Control
Have you tried the Power Apps grid control yet? If not, you should at least give it a go. As of now, this and any other entity controls like Calendar or Editable Grids can be only added and configured via the classic interface. To do that, navigate to the entity, then click on the “Controls” tab as shown below.
The relatively new Power Apps grid control allows users to seamlessly view, access, and modify records from views and subgrids. Additionally, other features include inline editing, infinite scrolling, nested grids, grouping, and aggregation. Power Apps grid control is the next evolution of the grids that will eventually replace all read-only and editable grids in model-driven apps.
More info can be found here: https://learn.microsoft.com/en-us/power-apps/maker/model-driven-apps/the-power-apps-grid-control
One more thing to remember, it is only possible to configure one default control for an entity.
When adding some controls to the entity, like Calendar control, they will be applied to all the views for that entity. However, it is also possible to add the controls to a single view. That be done either via the classic or the new interface.
Reference Panel
Reference Panel (Panel) can help to save up some space on a form and improve the overall user experience. Thanks to the Panel, multiple subgrids can be added to a single section on a form. They are already pre-built on some of the standard entity forms, but they can also be added to custom entities forms. Currently, it is not possible to add the Panel via the model app designer, it is only available in the classic interface. If you are not sure how to add it, watch my video where I demo that: https://www.youtube.com/watch?v=C-RbqteEZ_s
Section Properties
Form section properties can be changed using both interfaces. However, the classic one shows you a couple of extra options that are not available via the modern interface. The first one is the ability to “show a line at the top of the section”. But you know what? It does not make any difference to how the section will appear. By default, there always be a separator line between the section name and the fields and it can no longer be turned off. Also, options like “field label alignment” or “field label width” seem to be only the legacy features from before the unified interface was introduced and adjusting them will not make any difference to your form either. That’s probably why they were never re-introduced in the modern app designer and there is no point in trying to use them via the classic interface.
Modern App Designer
Modern App Designer is fresh, modern and... it uses shades of seance colour. What else does it offer though?
Autonumbering
Field autonumbering is a great feature that is used across various entities like Cases, Knowledge Articles, or Invoices. Moreover, it can be also used on custom entities.
Before the rise of Power Platform, autonumbering fields could be adjusted for the out-of-the-box tables via the system administration in D365 or using the Auto Number Manager tool via XrmToolBox. However, modern app designer allows you to create autonumber data type fields and configure the autonumber format. It is much quicker and easier to do it. And it also allows updating of the existing autonumber fields like the Knowledge Article number as shown below.
Records Viewing and Creation
When creating new tables and forms, I always run unit tests to make sure everything is configured properly. I find it so much easier doing this via the modern app designer as I can open a specific table and add new rows or edit the existing ones using the editable subgrid.
Also, I can see what records are already there, add or remove columns from the view or open the view in a new tab.
The record editing, new record creation or viewing of the existing records is possible through the app itself or advanced find. However, this way is accessible much faster when you’re in the middle of app creation and you want to minimise switching between different tabs.
View Editor
In my opinion, the View Editor in the modern app designer offers a much better experience than the one in the classic interface. It allows drag and drop of the columns to change their order and column width adjustment by moving the column dividers to the right and left. Also, new columns can be added easily from a list. Additionally, the modern View Editor displays all the records for the view allowing you to create and test the views in one go.
Plus, extra bonus is that the modern interface does not throughout an error at you like the classic does every time you want to change a column width (shown below). Was this bug there forever, or is it just me thinking that? Also, I don’t see it being fixed anytime soon if at all. So, if you do not like it, time for you to start using the modern experience to create and update your views.
Tools
An additional feature that is only available via the modern app designer only, is the “Tools” option which gives you the options as seen below:
Easy access to this information can help you when building e.g. Power Automate flows. It is an alternative to using e.g. Level Up extension as it allows you to get the info without opening the front end of your model-driven app.
Form Settings
The modern app designer also features “Form settings”, which the classic interface does not have. While you can change the form order and apply security roles to the forms using both interfaces, there are additional options available only via this feature.
First one is the “Fallback forms”. It allows you to set a default “backup” form in a case when a security role does not have a form selected. It is particularly handy when there are multiple forms and quite a large number of security roles as things can be missed easily. Or if there are any issues with displaying the default form for a specific role.
In addition to that, the Form Settings also has the “Form access checker” option, which allows you to check each of the existing security roles and what forms they have access to. Again, great when implementing quite tight security controls when you want to check that everyone has only the minimum access they require.
Conclusion
All the features that I have covered in this blog can be a great addition when building your model-driven apps. Therefore, whether we like it or not, we need to keep mixing and referring to both “building modes”, at least for now. Also, the above list has not exhausted the subject yet, but it’s a good start. If you are looking forward to seeing what else is only available in the either classic interface or the modern app designer, keep in touch.
コメント