When it comes to building Power Apps, I have a model that I follow to help me think about how the Power App should be constructed?  The starting point is the story.

Here is a story as an example.

In our country we have an issue of running out of blood in an emergency.  If someone is injured and in need of a blood transfusion, often the hospitals or clinics do not have the correct blood type available to provide to the patient, resulting in loss of life.  We need a solution that enables us to connect with people who can donate the correct blood types when this situation arises.

In looking at this short story, you are challenged to come up with a software solution to address this need.

When I think about building apps, I like to start with data and work from there, following eight steps to come up with a high-level architecture of how this problem could be addressed.  Some people take the approach of starting at creating the interface of the apps that will be used. I have found that leads to more rework later.

The first step I like to take is that of defining the data model; what are the entities that need to be created to model real-world entities? In this story, things that come to mind are physical entities such as hospitals and clinics, blood storage and inventory. Then I think about the people involved, from the story. I think about medical staff, patients needing the transfusion, donors who will supply their blood, and other admin staff.  I consider the activities that need to be performed as these will also need to make up the data model.  In line with the story I see the need to make a request for blood, collection of blood, storing of blood, data capture of patient details, data capture of blood types, and data capture of donors.

When looking at the entities that will be needed, generally they map to real-world entities as mentioned above. Each entity will need to have fields, required to capture the data for that entity.  Let’s take the example of the hospital. We may consider the following information essential to capture. Hospital Name, Address (multiple fields) Longitude, Latitude to name a few.  Here is a list of entities that could be considered for this application:

• Hospital

• Blood Stock Levels

• Blood Type

• Donor

• Blood Submission

• Patient

• Patient Medical Record

Part of creating the Data Model for the app is defining the relationships between the various entities.  How does one lot of entity data relate to another? In our example, we could see a logical relationship between the following entities:

• Hospital and the Patient

• Hospital and Donor

• Hospital and Blood Stock

• Hospital and Blood Submission

• Blood Submission and Donor

• Blood Submission and Blood Type

• Blood Submission and Blood Stock Level

• Patient and Patient Medical Record

• Patient and Blood Type

There will be more, but you get the idea.

What in the solution could be automated?  It may be automated emails that are triggered by an event happening or automatically updating data in one entity from data in another entity. It may include business rules that automatically trigger when a condition is met like bloodstock levels for a specific blood type dropping below a threshold.  Or it could be an automatic notification message sent to all known blood donors within a five-mile radius for the specific blood type needed.

As part of the solution you should question what integration is needed. In this example there may be a need to integrate to a real-time mapping service to show the distance from the address of the Blood Donor to the Hospital. Also, there would need to be an integration to a messaging service that allows the broadcast of a message to the potential donors, so they are notified in an emergency.

Another question to ask is how AI should be incorporated into the solution.  Could AI be used to predict the needed for specific blood types before an emergency?  Are there particular situations that create higher demand? Are there patterns that can be identified in donor patterns?  Nowadays every solution should be considered for AI since we are still learning about the ever-increasing role AI can play in improving our lives.

What insights and reporting will the application require?  Who needs the information to make a decision? What format will this information need to be in?  Will reports be run on-demand or as needed?  Will the reporting trigger other events and activities?  What environment will the reporting and insights be consumed in? The information, format, design, and context are all essential to understanding what is going to be needed when it comes to insights and reporting.

Surprisingly for many that bring us to experiences. Or the interfaces of the solutions that are built.  It is at this point we ask what experiences people will need to read, input and interact with the data.  In our story it was identified that we needed experience for donor submissions and hospital staff operating at a computer.  For donors, an app was needed to capture their personal information including blood type, address and willingness to be involved.  Hospital staff needed to interact with patient records, bloodstock and donor information.  It's at this level that you can decide if a Unified Interface or Canvas App experience is required of it a PowerApp Portal provides the experience needed.

Once these steps have been actioned, you can then model these requirements in the Common Data Service (CDS).  Many of the decisions should be made before you start building the solution on the Power Platform.