System Design

The heart of this project is Power Apps, through which we did most of our development. It dynamically generates the Portal and Model-Driven App using Liquid to populate the Portal. The Portal is populated with data stored in Dataverse, which Power Apps communicates with and provides an interface for development (directly in Power Apps or through the Model-Driven App). Power Apps also integrates Power Automate to perform logical operations on Dataverse data based on triggers from the Portal interface (e.g., form submission, which is interpreted as a record addition). Power Apps also supports custom JavaScript code for additional custom functionality, which we used to implement automatic matching functionalities. The logistical aspects of each of these functionalities (aside from the custom JavaScript) is taken care of by Power Apps.

Below is a site map depicting the pages which can be accessed, in any order, with each of the 3 possible web roles.

Our solution's database consists of 13 tables, 1 default table, and 12 custom ones. More detailed information about these tables can be found in the implementation section, however, simply, they are as follows:

Default Tables

  1. Contact

Custom Tables

  1. ACM Classification Codes

  2. FYP Options

  3. Research Groups

  4. Student-ACM

  5. Student Responses

  6. Student Topic Options

  7. Supervisor-ACM

  8. Supervisor Responses v2

  9. Topic-ACM Map

  10. Research Group-ACM Map

  11. Supervisor-Student Pairs

The tables are related in the following fashion utilising multiple 1:N, N:1, and N:N relationships. More info on this can also be found in the implementation section.

There are no public facing APIs or packages involved in our project. All of the code is entirely self contained within the localised content of the pages in our portal. There are multiple APIs that exist within our solution, mentioned in the implementation section. By nature of how they are created within PowerApps, they are usable by the public, however these are purely to kept private to stop any potential leaks of information.

Since, as mentioned, the code that completes our matching algorithm is embedded into the portal page containing the button for the administrator to run it, there are no packages involved, and no dependencies. All of the functions used in the code utilise JavaScript functions that almost all modern browsers have support for.