Enforcing the latest version of your Power App

You may also like...

3 Responses

  1. Srinivas Thota says:

    Thank you so much for writing a detailed blog on browser caching issues with PowerApps.
    It would be great if you could clarify couple of queries here:
    1. I believe at times, even with reload of the app manually, PowerApps is unable to pick the latest version. So I think the problem may still persist even if we implement this work around unless we clear the cache of the power app when launching it. Sometimes I also feel that it takes a bit of time to load the latest app even after clearing the cache.

    2. Also, what do you think of creating only one table App_Versios with 3 parameters such as DEV Version, Test version, PROD version so we do not need to connect the table in every environment and modify the logic accordingly when we promote to the target environment.

    We have been facing these issues in our app for a long-time now. Thank you once again for putting up all details here.

    • iAm_ManCat says:

      Hi Srinivas,

      Thanks for reaching out – happy to clarify your queries as best I am able:

      1. The caching will always be on the browser side, so if there is a lack of refreshing, this is the browser’s fault (this can be proved by opening the App on a computer that has never opened the app). However, you are right in that there is an approximately 0 to 2 minute delay between hitting publish and the newer version being made available for consumption.

      2. In this example I created three tables, one for each environment – the idea was that in the case of Dataverse, you would HAVE to have three separate tables as you cannot reference a table in another environment (however in Dataverse, you could have them all be the same name as you would be promoting the solution through rather than having three with different names).
      If you are using SharePoint, I would still advise using three tables, and you could reference them with an environment variable that points to different tables but uses the same variable name between your solutions.
      What you have described using a singular list with a column for the parameters is possible, however it’s not something I would advise as there is a lot of room for accidental error and we should, where possible, not have our dev/uat/prod data intermingled.
      I’ll give you an example of why we try and mitigate the potential for downtime/damage – let’s say someone changes the column type for your VersionNumber from text to number – that would immediately break all apps connected to the list – if there are three separate lists then either dev OR prod OR uat are affected but only one of the three, but if you have one singular list and something goes wrong, then all versions will not work.

      I hope this helps shed some further light on it – let me know if you have other questions around this!

      • Srinivas Thota says:

        Thank you once again for clarifying my queries with the detailed explanation.

Leave a Reply

Your email address will not be published. Required fields are marked *