Your Power Apps user settings are probably wrong

When you’re starting to use a brand new computer or phone, usually one of the first things you’re presented with are these questions:

• What language do you want me to speak?
• Where are you located?

This allows the device to understand not just the preferred UI language and your physical location. It also enables it to make educated guesses on:

• Which formats make sense to you for number, date and time fields.
• What time zone you are living in.

Now, let’s move from devices to software, namely model-driven Power Apps. Do you recall seeing similar onboarding prompts when starting to use (or build) apps? Nope, Microsoft doesn’t ask such questions.

“I guess they already have that information and are automatically setting things up the way I want them.” Yeah, you might think so. That’s a false assumption, unfortunately. Changing your Microsoft 365 account settings for your tenant isn’t going to get synchronized down to the business applications used in the MS cloud. Meaning, this selector here has no impact on the apps that live in Power Platform environments:

Power Apps canvas apps follow the regional settings from the user’s browser. This can lead to confusion as well, but at least the field formats should be something the users encounter on other websites. In canvas apps there is also the ability for the app maker to force specific locale settings per each control in the app UI. See examples in this article.

Model-driven Power Apps include Dynamics 365 apps from the CRM side. I would guess that for a sizable share of model-driven Power Apps users their settings are likely to be at least partially incorrect. What’s worse is:

1. Fixing them is quite unintuitive.
2. Admins can’t do much to help users with this.

In this post I will explain the parts of the Power Platform user settings management story that are broken today. My intention is to spread awareness on issues that many app makers and admins may have ignored, and which their app end users may be suffering from.

In a follow-up post I’ll provide an example of a solution that could make life easier for everyone who uses, deploys or administers Power Apps.

First: blame CRM

There are many great benefits that Power Apps has gained from being merged into another Microsoft platform that first saw the light of day as Dynamics CRM (well, “Microsoft CRM”, to be precise). User settings management is not one of them, unfortunately.

The user settings functionality probably served its purpose back in the on-premises days of CRM servers. Today, this legacy from around two decades ago creates some incomprehensible experiences for an audience many times the size of that which ever interacted with Dynamics CRM.

Power Apps, be it canvas or model-driven apps, live inside Power Platform environments. It is becoming a standard feature that such environments include a Dataverse database. This is essentially what one CRM database was back in the days. Today, larger tenants may easily have hundreds of such database instances.

Dataverse hosts many essential parts of Microsoft’s low-code platform. It provides the solution framework for moving apps and related components across dev-test-prod environments, for example.

There are hundreds of tables (previously “entities”) in the standard schema, with some being meant for storing business data and others for data needed by the system itself. The User Settings table is what the topic of this blog post revolves around.

Each to their own (format)

When your app is connecting to tables in Dataverse and presenting it to the user, the decision of the number, currency, date and time field formats is made on the server side. It defines whether your app UI shows “one million dollars” as:

• $1,000,000.00
• 1 000 000,00 $
• $1.000.000,00

Or any other variation. The place and purpose of dots, commas, spaces, currency symbols depends on what the format has been set to on the database side. For each user account.

That’s the important part: it’s not a global setting of the database/environment. Every user may see different things. We are all different as human beings, and it’s a wonderful feature for the system to reflect that as well.

Us humans are also wonderful in our abilities to interpret what the format being used by the system might be. All the three examples above would say “one million dollars” to most people, even if only one format is the official sequence of strings used in whichever region they live in.

With dates, it can be a bigger struggle. Today when writing this blog post, the date is 2/3/2023 – for some part of the world. If you come from the land of Microsoft, it means February 3rd. For basically everyone outside the US, it would mean March 2nd (which is the correct value here). ISO 8601 would be the best format from a logic perspective, yet for some reason 2023-03-02 hasn’t become the norm. Oh well.

We may be able to guess the right date format based on context. Where it gets really dangerous, though, is with time zones. They are invisible to the app user and you’ll have no way to know whether you’re seeing the correct value in any date field of the app.

Why’s that? Because dates in Dataverse are often stored in date and time columns. This means that while the clock on my PC currently says “2023-03-02 21:10”, the user looking at a record in Power Apps may see:

• 2023-03-02, or
• 2023-03-03

In Finland it’s March 2nd, but in India it’s already March 3rd. Not only is the value that’s shown to the user determined based on their time zone setting. It also affects the value that is written to the database when the said user enters new/updated data.

There are ways to get around this dilemma, using Date Only or Time-Zone Independent columns in Dataverse. That’s not going to help the app end user, though, since A) the column type it’s not visible to them nor B) configurable for their preferences.

One classic gotcha of the time zone settings is that they affect all user accounts – also calls made via the API instead of the UI. If you’re writing integrations to or code running inside Dataverse, you’ll need to dig a lot deeper into the topic than the shovel that I can give you is good for. Head towards a blog like Scott Durow’s and learn from the master.

Setting the user’s own settings

Now that we’ve established that user settings like time zone and field format are very important things, let’s look at how a user can make sure that they are indeed set correctly.

Say you’re using a Power Apps canvas app and want to check your user settings. Where do you click in the app? That’s the neat part: you don’t. Even if you have the Power Apps navigation bar visible (which might have been hidden intentionally), none of the menu options give you access to the user settings used by the app.

OK, let’s assume that you have been granted maker level access to the environment hosting this app (end users often will not have this option). We go to the Maker portal on make.powerapps.com and click around the similar cogwheels.

From under “Power Apps settings” we get to a promising menu dialog that has a “language and time” tab. Unfortunately, there’s nothing related to time in there. Furthermore, we’re not looking to change our language settings, rather the regional format.

Most people will have already given up at this point. Yet if you’re not afraid to click on obscure menu options, you might find a model-driven app in the same environment. Like the omnipresent Solution Health Hub that Microsoft wants to provision everywhere without asking for permission. This time we’re actually lucky to have it as the only model-driven app in our environment.

Let’s open it up. Don’t worry about that “Active Analysis Jobs” view that opens by default, no one understand what these things are about. What we’re really hunting for is cogwheels and we luckily do discover a new one, in the exact same place as the earlier ones. This opens with a promising menu option: “personalization settings”.

“NOOO!!! MY EYES!!! WHAT IS THIS THING?!?!?” No, don’t panic. You’re in the right place – even though it looks like nothing you’ve encountered in Microsoft 365 apps. What we have here is the classic Dynamics CRM web client UI presented inside a modal dialog window of the Unified Interface. Yes, it reads “Dynamics 365” everywhere but trust me, this is part of Power Apps.

On the General tab you’ll find the Time Zone dropdown menu. If it reads something else than you expected, change the value now. Then hop over to the Formats tab and do the same check/change for the Current Format field.

Click OK. Close the window. Take a deep breath. You made it.

Just don’t forget what exactly you did to get to the user settings screen. Because these settings are environment specific. The next time an internal app is deployed in your organization, it may well be hosted inside a different Power Platform environment. With user settings that are completely independent from the ones you just updated.

“As an administrator, I want to end the pain…”

Given how many potential blockers there are for a Power Apps end user to ever discover nor even be allowed to navigate to the user settings screen, this is something the Power Platform administrators should definitely look into. Is there a way to change the settings on behalf of another user?

Let’s find out. We’ll go to PPAC (Power Platform Admin Center) and navigate to the environment. From the Users list we open up one user account and study the options available.

We see a nice flyout menu that resembles Microsoft 365 admin center experience in many ways. Unfortunately it doesn’t contain anything related to time zone or format settings. Behind the three dots, there’s a “Manage user in Dynamics 365” option. By now we’ve already become aware of how broadly Power Platform relies on things that say “Dynamics” so we know we probably have to click on it.

The initial loading of the page may take a few seconds/minutes/weeks, but once it opens up we see… OH DEAR LORD!!! Not only did we move to Dynamics 365, we actually travelled back in time into CRM 2013 user interface.

We’re presented with notification banners shouting scary things at us. We have a form that contains fields, grids and feeds that seem to be design to just confuse us. We have an endless menu bar with options like “reject email” (wouldn’t we all want to reject it?) and “change position” (would fetal position be a good option right now?).

What we don’t have is access to any of the user settings. This is by design. Sure, no one said it’s a good design, but it is what it is. The answer to our original question is: there is no out-of-the-box option for system administrators to change user level settings on behalf of another user.

It’s design like this that has given inspiration to a countless number of community tools, many of which are available in XrmToolBox. If you need to administer Power Apps that have any dependencies to Dataverse, the first thing on your To Do list should be installing this software on your local PC.

XrmToolBox User Settings Utility is the plugin you’ll want to reach for in the toolbox. Once you establish a connection to a Power Platform environment (always choose the “Microsoft Login Control” option, btw), you can click “load users and settings” to see every user account in the environment. Select one of them to check the current values.

Not only can you modify the settings (time zone, format and many more) for another user. You can also do this in bulk for all selected users. “Woohoo! Now the settings are fixed!”

Until the next user comes along. Or you have a new Power Platform environment that needs equal treatment. Again and again. Being a desktop application, you unfortunately can’t automate the actions that XrmToolBox does. Well, unless you go crazy with Power Automate desktop and build an RPA bot for this…

Is there any better way?

The bright side of having the user settings data stored in a Dataverse table is that we are empowered to use the platform’s tools to build user interfaces and automations for managing it. With low-code.

I have come across a few blog post with examples of how to use Power Automate cloud flows and/or Power Apps canvas apps to update the user settings. For example, my colleague at Forward Forever, MVP Timo Pertilä, recently wrote an article about how to set the number formatting for model-driven Power Apps (auto-translated from Finnish).

As it just so happens, I had also started exploring these possibilities at the exact same time as Timo. My approach is a bit different, since the goal was to resolve the issue not just on a single environment level. So, I’ve created a tool that allows any user to go and update their own settings across multiple environments. Stay tuned for my next blog post where I present the solution.

Cover photo by Alexander Schimmeck on Unsplash