Model-Driven Apps Summary

The choices we make when it comes to data modelling not only impact our users and their experiences directly but also reporting, integration, and nearly every aspect of the system. While it is possible to fix data modelling problems later it requires rework and data migration. So spending time on a data model up front is well worth the investment. In our data modelling module we went through several items to include fundamentals. And I realise that the term overview here that we see sounds so lightweight and simple but for data modelling it’s anything but simple.

All of the moving parts for the application need to be built and modelled in such a way that it makes sense to not only our users but to our stakeholders as well. We have many choices when it comes to field types and in this section we helped you understand how to choose the right type. For our hands on for this we are starting to really build out our knowledge assessment application. You were building new entities, adding calculated fields, doing lots of things here to begin to really see the potential for our application. Relationships are how we model real world connections between entities. One to many and many to one are the same thing looking in from opposite directions.

The system can help us make many to many relationships with a hidden intersect entity but we can also manually create our own many to many relationships. Each of these relationships come with behaviours we can set, such as, delete behaviour, parental or referential Behaviours, and more. Behaviours help us by implementing automation to keep the data clean. For example, if you delete a parent record it controls if the reference to a child record is simply removed or if the child records are deleted. This ensures that you don’t have unexpected orphan records in the system. In our hands on we created the relationships and Behaviours for our knowledge assessment application.

Under other entity options we discussed auditing and how it needs to be enabled and configured at a few different layers within the system. It’s system level, entity level, and field level. As we built out our entities we were aware of our definitions that maybe can’t be changed later. Some things like the schema name, including the prefix we use, ownership type, activity type, queue participation, and other items that you see here on the screen that are marked by our little icon here that will tell us if these things can’t be changed once we have enabled them. For our hands on for this one we added auditing and feedback for our assessment app entities.

In our other field options we covered the many ways to display the data on a form. Sometimes it’s easier for a user to have visual cues to help them out. So we have choices of how we can put things here on our forms. As a reminder, right now we’re in a transitional time for our platform. Some of the display options are part of the classic web experience and some of them are part of the unified interface. We went through some internationalising options. Whether it be currency or languages we have many choices that are available to us to both manually and automatically handle some of those configuration changes for our international audience.