Improving my account creation app with Dataverse

This article covers the first major update to my app. The original version and overall use case are described here.

I kept the first version of the app very simple. It worked well for the basic account creation process and gave me a good starting point for the overall use case.
After using the app in practice, I noticed a few areas where the solution needed to become more robust. The most important change was the introduction of Dataverse to separate the app from the flow. In addition, I also improved the handling of more complex names, like multiple first names or last names, and added a normalization step.
In this article, I describe these changes and the reasoning behind them.

Using Dataverse to decouple the flow from the app

In the first version, the app called the flow directly. This worked well for the initial setup, but it also meant that the app and flow were tightly connected.
In the next version, I changed this part of the design. Instead of calling the flow directly from the app, the app now writes a new request into a Dataverse table. The flow is triggered when a new row is created and then processes the account creation in the background.

One important reason for this change was the behavior after importing the solution into another environment. By separating the app from the flow through Dataverse, the app becomes less dependent on direct flow connections at runtime. In my case, this helped reduce the connection prompts when the imported app was opened for the first time.
This also changes the role of the app. It is now mainly responsible for collecting the request, while the provisioning logic starts afterwards from Dataverse. For me, this made the overall design easier to understand and easier to extend.

Handling multiple first names and last names

Another change was the handling of names. In the first version, I worked with the simple assumption that a person would have one first name and one last name. For the initial scope, that was enough, but it does not always match real names in practice.
I therefore adjusted the logic to support multiple first names and last names as well. The app can now accept name inputs that contain several parts separated by spaces, which then need to be handled differently depending on where they are used later in the process.
For the alias, I remove the spaces from the first name and last name values first and then combine both parts into a single value. For the display name, I use a separate path, because there I want to keep the natural spacing and only remove unnecessary extra spaces. This made the handling more realistic and better aligned with the actual purpose of each field.

Normalizing names for consistent processing

After adjusting the handling of multiple first names and last names, I also added a normalization step for the alias. This was relevant for names that contain characters such as umlauts or accents, because these values are later used in a technical field where a more normalized format is helpful.
I decided not to normalize the first name and last name parts separately. Instead, I first created the combined alias value and then applied the normalization only once to that final string. For this small solution, that felt like the simpler and cleaner approach.
I did not use the same logic for the display name. There, I wanted to keep the natural spelling and spacing, apart from removing unnecessary extra spaces. This means that alias and display name now follow different processing paths, each based on their actual purpose.

Final thoughts

This update started with relatively small functional changes, but it also led to a broader adjustment of the solution design. For me, that was a good reminder that even simple Power Platform solutions often evolve once they are used in practice.
In this case, the result was not just better handling of names, but also a structure that separates the app and flow. That makes the solution easier to understand and gives me a better foundation for future changes.