This is a continuation of a 8-days series of Power Platform. For the rest of the series, please refer to links below:
TL;DR — Day 1 Recap
Day 1 is about a simple and concise overview of Power Platform — the different components and the scenario which I will used as my exploration.
Referencing back to the scenario requirements, we need to determine the components from the platform to deliver this scenario.
I came across multiple blogs/websites/community sites on how to get started with power platform. However, it’s important to plan and structure your thoughts before jumping in. I like how nz365guy’s 8 steps to Building PowerApps and also the number “8” which is quite apt for this series.
Approach — 8 Steps to Building Power Apps
Building any application always start with a story or scenario, and it’s not about jumping in and start developing an interface. By following these 8 steps, you will be able to come out with a high level architecture of how to fulfill the scenario requirements. The 8 Steps as follow:
- Data Model
- Artificial Intelligence (AI)
Step 1: Data Model
To summarize the key points that Mark Smith mentioned, it is simply defining the physical entities (i.e. locations, places), people involved and activities between the different objects. Below is my initial draft or attempt to begin with (This is just a very simple use-case):
I had other drafts as well but I was overthinking this and decided to follow the simple principle — Keep It Simple and Sweet (KISS). Being in line with the scenario:
- The user will either give/receive ang bao to/from different people during visitation. [KISS]: There is no requirement to track the specific person (name) whom the user has given/received but some ways to label the significance of the ang bao (i.e. immediate family, relatives, friends, misc).
- The user can plan for plan for visitation.
Step 2: Entities
After identifying the key entities, you will need to identify the relevant fields to capture the right information. Below are the entities considered for this application:
- Ang Bao
Taking the entity “Ang Bao” as an example, these are the fields for consideration as shown below:
- Category: As mentioned in Step 1, the assumption is that there is no need to track the person whom the user have given/received but some ways to label the significance of the ang bao.
- Amount: The total amount given in the ang bao.
- Denomination Type: Chinese also like auspicious numbers — The number 8 has a similar pronunciation as ‘fa’, or ‘Huat’ in Chinese dialects, which suggests the idea of flourishing. So, if you want the recipient of your ang bao to prosper even more, you can give denominations that end with the number 8 (for example, $8, $18 and so forth). For example, there can be multiple ways to represent $18 in different denominations such as having 1 x $10 with 4 x $2 or 9 x $2. The application need to be able to track the different denominations of each ang bao based on an amount.
- Is Given: A boolean way to determine if this ang bao was given or received. Having a boolean (true/false) reduces the need to create additional and similar entity.
Step 3: Relationships
The logical relationships between the entities are defined in the diagram in Step 1. The cardinality ratio was also added — defining the association/type of relationships between entities:
- One-to-One (1:1) — A single entity instance in one entity class is related to a single entity instance in another entity class.
- One-to-Many (1:M) — A single entity instance in one entity class (parent) is related to multiple entity instances in another entity class (child)
- Many-to-Many (M:M) — Each entity instance in one entity class is related to multiple entity instances in another entity class; and vice versa.
For example, each user can give many ang baos, and one ang bao can only be given by one user as shown below:
Step 4: Automation
Based on the requirements, there are some areas for automation:
- Automatically notify the user when the given amount of ang bao for the day is more than the threshold.
- Instead of handling the “Amount” data input by user where it needs to tally with the different denominations, the sum can be automated as part of the business process.
Step 5: Integration
Integration refers to the need to integrate with a first or third party service to achieve an outcome. For example, based on the address stated in the entity “Place”, the application can integrate to a real-time mapping service to show the distance from the current location based on GPS to the next place. At the moment, I could not think of any integration and will explore later.
Step 6: Artificial Intelligence (AI)
Well, is there really a need for AI in this scenario? At times, it’s not about having the latest and greatest technologies in the application but the usability and the need.
For Power Platform, AI Builder is a new capability that citizen developers can add intelligence to the application with minimal coding or data science skills. Basically, any user can easily build, train, and publish AI models without writing a single line of code using pre-built or configurable templates and a guided process.
There will be a deep dive in AI Builder along the series and I will just assume that there is no use case at the moment for AI.
Step 7: Insights/Reporting
Part of the key requirements, user should be able to track and analyze the ang bao details — total amount, breakdown based on category, different types of denomination.
Step 8: Experiences
This would be the easiest step among all — how would the user be accessing and interacting with the application?
From Power Apps perspectives, there are two types of apps an user can create — Canvas or Model-driven apps:
- Canvas apps start with your user experience, crafting a highly tailored interface with the power of a blank canvas and connecting it to your choice of 200 data sources. You can build canvas apps for web, mobile, and tablet applications.
- Model-driven apps start with your data model — building up from the shape of your core business data and processes in the Common Data Service to model forms, views, and other components. Model-driven apps automatically generate great UI that is responsive across devices.
The internet has tons of resources on the differences between the types. My view on the key differences is — Flexibility vs. Structure.
If you need flexibility to control the user interface and experience, go with Canvas apps. The user will have full control over every single aspect of the application.
If you want control and rapidly configure business processes, forms and process flows, Model-driven apps would be suitable. Much of the layout is determined for the user and largely designated by the components you add to the app — it’s a component-focused approach to application development.
Based on the above approach, it is quite straightforward to determine the core components I need for this Power Apps — Canvas apps with the use of Common Data Services (CDS)
I will choose to use Canvas apps as it will be interesting to push the boundaries to develop turn-key controls or layouts.
Common Data Service (CDS)
The use of SharePoint or Excel is a common starting point for data source when it comes to Power Apps development. However, SharePoint or Excel is not relational database. Common Data Service is the preferred data layer for Power Apps.
Microsoft provides 6 key reasons on why you should use CDS:
- Easy to manage
- Easy to secure
- Access your Dynamics 365 Data
- Rich metadata
- Logic and validation
- Productivity tools
If one of the main reasons is having a relational database, what about SQL? However, the main objective of Power Platform is to:
Allowing citizen developers to develop and innovate with intelligent applications without the need to worry about the programming platform(s) or where the data resides — be it in a database, flat files etc.
For any citizen developers without the experience to design and maintain SQL, it would be a daunting task! CDS can easily remove this obstacle and provide an enterprise-grade data platform, allowing users to store and model business data easily and securely.
Conclusion of Day 2
Day 2 focuses on following the suggested 8 Steps to help and guide someone new when it comes to developing on Power Platform. With some planning in place, it will be easier to nail down the key Power Apps component and process with the next steps.
I have covered some depth about Common Data Service and this will be the focus for Day 3 — understand how to utilize this component and translate the data model/entities/relationship for this application.
Happy #powerhacking away and thank you for your support!
The opinions and views expressed here are those of my own and do not necessarily state or reflect those of Microsoft Singapore or Microsoft Corporation.