Model-driven PowerApp: Best practice to display subgrid of records with no appropriate primary column name

Background

Each Dataverse table contains a primary name column. When displayed in a subgrid, clicking on the primary name column will navigate to the form so that the user can edit that row. Most subgrids in my application work this way.

The Problem

I have a Course form with a list of participants displayed in a subgrid. The subgrid displays each student's name (as a link) and the grade received in the course. There is no appropriate primary name column for this Participant table. To edit the participant record, the user must select the row in the subgrid, then click the subgrid's Edit button. As a result, this UI is different from all other subgrids in the application and I know that user's will click the student name to try to edit the participant record and be confused when they are presented with the student record.

Am I missing something? Is there a better way to handle this?

It's a common problem I face quite often. Here is usually what I would do.

Make sure the Primary Name Column always contains relevant information to the user to be able to quickly identify a record. Sometimes it requires copying information from one or multiple other columns into the primary column.

In your case that would probably means concatenating the student's name and grade.

How to do that?

Common to all solutions below

• Use one of the following solution to copy the content of one or several fields into the primary column.
• Make sure the solution you select also updates the content of the primary name column when one of the copied field is updated.
• Remove or hide the primary column from the form, the name of the record will be displayed at the top of the form anyway and you probably don't want users to play with it.
• Display the primary name column in every subgrid.
• I would recommend not adding the fields copied into the primary column in the subgrids to avoid confusion.

Solution 1 - Classic Workflow

• Create a classic workflow that runs when a record is created / updated

Pros:

• Very quick to put in place
• Runs synchronously (users will see the name updated in real-time)

Cons:

• Not very practical if you need to add business logic (using different fields as source depending on a certain condition for example)

Solution 2 - Power Automate

• Create a Flow that runs when a record is created / updated

Pros:

• You can implement complex business logic in your Flow

Cons:

• Runs asynchronously (users will have to refresh the page after the creation of a record to see the record's name)
• According to Power Automate licensing that flow would certainly be considered as an "enterprise flow" and you are supposed to pay 100$ / month. That specific point must be taken with a grain of salt. I had several discussions with Microsoft about it and they haven't given me a clear answer about what would be considered an enterprise flow.

Solution 3 - Plugin

• Create a plugin that executes when a record is created / updated

Pros:

• You can implement very complex business logic in your Flow
• It can run synchronously

Cons:

• Pro-code (I put it as a con since Model-Driven App is a low-code / no-code approach but there is nothing wrong about pro-code per say)
• Developing a new plugin for each entity where you need this logic is kind of overkill in my opinion. I would consider developing something very generic that would only require some sort of configuration when the logic needs to be applied to a new table.