Showing results for 
Search instead for 
Did you mean: 

Add an event/property in PowerApps to detect when the loading completes i.e. when the dots moving on the top of the screen stop

At times, the data in the form takes longer to load (symbolized by the moving dots on the top), users quickly click on save before the data is completely loaded, therefore overwriting some of the fields with blank data (so data is lost). The "loading" dots are still sliding left-to-right at this point, but users miss it.


An event/property is required which tells us that the data is still loading so that we can either hide the form or show a splash screen over it until that event (loading completion) occurs, and then hide the splash or show the form.

Status: New
Kudo Kingpin

YES! I have been wanting this for years now.

It shouldn't be difficult to block the users from doing things until everything has loaded. I have my own loading variable that is set to true at the beginning of all code and false at the end, but not all code waits for the server to finish before powerapps considers it completed, so this does not always work.

Not applicable

@Boneckrh19 True that, we've a form with multiple combo boxes with default selected values, since the default selected value are coming from AD, it takes time for the default selected items to populate as the API call to search the item is still happening at the backend. The user- fast and smart, hits save and boom, data is lost (because the default item is not selected yet), face client escalations. No work around this. 


Have you been able to come up with workaround for this.? 


we are also setting our custom variable to show loader before executing the code and stop showing loader after executing the code. the problem for us is that we've a form that's waiting to be fully loaded and we can add variables to determine if a form is completely loaded.

Kudo Kingpin

@Anonymous the only workaround I can think of in that case is to change the displaymode of the save button to something like this

If(IsBlank(Dropdown.Selected.Text), DisplayMode.Disabled, DisplayMode.Edit)

This might work? Perhaps add a message on the screen with that IsBlank in the visibility property, something like "the server is still loading, please wait a moment to save"

Not applicable

@Boneckrh19 Boneckrh19 Unfortunately, we've ~60 combo boxes not just one, and the values are optional so you can't really know if the combo box inside the form has loaded completely or not. And comparing those 60 Como boxes values against the DB is big no because we've 8 screens like that maintaining it will be a havoc.



Kudo Kingpin

@Anonymous sound like what you need is exactly what you asked for; a way to tell if the app is still loading something!

My only other thought is to load a test value. Put a dropdown in the form, (doesn't even have to be visible,) that defaults to something from that same table. That one can never be changed and will never be required, so you can use it as the basis for the whole form. If that one is blank, that means it has not loaded the default selected value and the server isn't done. You can check just that single dropdown in the displaymode and visibilities. One per form.

Not applicable

@Boneckrh19 we are doing exactly the same, but we don't hide the Como box else it won't load, he made the height as zero, but currently we are at the mercy of PowerApps, sometimes this doesn't work and sometimes it does. not bullet proof.

Advocate I

This is a must have, even if we open up a screen with a form. The form does some stuff in the backend that we have not initiated. We need to know when that work is finished. Once the form is ready to use then and only then we need to display the form to the users. 

User opens up a screen with a form

  • Form is doing some stuff in the backend, we see dots on top
  • Default data in the form is still not updated, user thinks that the data wasn't saved earlier.
  • User selects the data again and submits the form while the form is still doing it's thing.
  • It would be good to know when the dots are stopped so that we can allow users to interact with the form.
Advocate III

I agree.

Dealing with the Asynchronous Nature of PowerApps is the most challenging aspect of the Power Platform.


(The second most challenging being the extremely buggy Flow interface that sometimes completely ignores your formula edits, or just decides to completely change your formula for no apparent reason).


There are MANY areas of PowerApps that are asynchronous - take the Form "OnSuccess" function - sounds like it should run once the Form has successfully saved? Unfortunately not - If you put code in that function that looks at data on the Form - you will get all sorts of funny results, because although the Form has technically "saved", it performs a "Reset" at the same time as the OnSuccess Code is executed, so all sorts of the values are part-loaded, and some of the Controls are all over the place.


The ONLY way to account for these RACE issues is with extensive use of the Timer Control - really not ideal for Users. It's a strange state of affairs that the developers have to purposely SLOW DOWN the User ecperience in order to work around the pitfalls of PowerApps.


Please give us events for monitoring/managing when PowerApps is multi-threading or doing asynchronous queries or updates.




Kudo Kingpin

@james_hathaway I have forgone the use of SubmitForm entirely for some of the reasons you said! I use Patch for everything because then I can at least control the order of events for certain. Even though this means manually implementing error messages and catching invalid entries before they can even save.


The Select function is another odd one for asynchronous implementation. I can tell one button to trigger another, but no guarantee that the triggered button will finish its code before powerapps moves on to the next line in the first button.

Advocate II

Must have requirement.
Thanks for raising it.
Microsoft should work on it priority basis.