Showing results for 
Search instead for 
Did you mean: 
Level 8

Patching global variables from input controls breaks type validation

I have come across a problem where by when I try to create a formula for patching a value in a Global Variable (record) the type validation breaks everywhere in the app that the Global Variable is Referenced and I get yellow triangles everywhere.

Once it has broken it will stay like this until I close the app and re-open it for editing.

Sometimes if the formula is correct the errors will go away and it will work, other times even after closing and opening I still get errors everywhere and I have to remove all reference to the Glabal Variable and re-input them to get it to work again.

This has become very time consumung as I have a Global Veriable referenced in more than 20 places, accidentally changing one character in a formula cn tigeer this and then i have to go and find everywhere I am referencing the Global Variable, remove them and start again.


I am using Chrome and web studio for editing, to re-create the problem try the following:


Required Controls:


Button1 - Button Control
Button2 - Button Control
Button3 - Button Control Toggle1 - Toggle Control Some labels with their Text property set to: gVar.Number gVar.Text gVar.Bool


 Button1 - OnSelect 

Set(gVar,{Number:1234, Text:"text", Bool:false})


Button2 - OnSelect 

Set(gVar,{Number:5678, Text:"moretext", Bool:true})


Clicking these buttons should now change the values displayed on the labels.


Button3 - OnSelect 


 If the formula goes in correctly you should be able to click the button and change only the gVar.Bool value.

If you remove the "Value" part from Button3.OnSelect and re type it in you will get yellow triangles and the labels where the gVar values are referenced will display nothing.

From then on the gVar Global variable will be useless in the app untill you close the app and re-open it.


I know I could split all of the fields in my Global Variable into seperate Global Variables but the Global variable I am using in may app has 28 fields and re-coding all the referneces to them would take quite a while not to mention the inefficincey of calling Set() 28 times instead of calling Set(Patch()) once.


I have noticed that if I only use the Set() funcition for the Global Variable in one place then Set(Patch) it all works fine it becomes a problem when I am using Set() from multople controls on the same Global Variable e.g. Button1 and Button2


Is there any way I can avoid this error and not have to keep closing and re-opening, and resetting my global variable references?

 Any help would be greatly appreciated.

Level 10

Re: Patching global variables from input controls breaks type validation

Hi @SimonMeadows, great post.  Identifies the issue clearly IMHO.  I have no bright ideas, unfortunately PowerApps is strongly typed but does not have a clear variable declaration syntax, which often results in a mess.

Maybe the team at PowerApps have an idea.

Copying @rc and @v-micsh-msft and @audrieg and @carlosag and @CarlosFigueira

Level 8

Re: Patching global variables from input controls breaks type validation

Thanks @Meneghino,


I have been thinking about it and I wonder if it is to do with the type coerision in some way.

I have noticed there is a great deal of type coersion which in a lot of places makes referencing values much easier but it is not consistent or well documented where and when type coersion is used.


You can assign just about any type of single value field or variable (text, date, time, number, boolean etc.) to a Label control and it will be coerced somehow into text to be displayed on screen, but there is no way to see or debug when the type coersion happens or what the types are at any particlar point.


e.g. If I have a Toggle control, it's Value property I would assume is Boolean (true or false) but this value is not consistantly coerced between Controls and Functions:


Given these Controls:
Toggle1.Default: false
Label1.Text: Toggle1.Value
Toggle2.Default: Toggle1.Value
Toggle3.Default: Label1.Text

Label1 will show the current value of Toggle1


Toggle2 will show the current value of Toggle1

Toggle3 has an 'Invalid Name' error because the type of Toggle1 is changed to Text automatically by the Label Control, but the type of the label control is not changed back to Boolean at Toggle3


In simple situation such as these it is easy to see where the type coersion is not happening and easy to fix but take this Set() for example:


    'Selected User':               inputUser.Selected,
    'Start Date':                  Now(),
    'Start Hour':                  09,
    'Start Minute':                30,
    'End Date':                    Now(),
    'End Hour':                    17,
    'End Minute':                  30,
    'Holiday Days':                1,
    'Overtime Selected':           false,
    'Overtime Hours Time':         0,
    'Overtime Hours Time Half':    0,
    'Overtime Hours Time Double':  0,
    'Buyout Amount':               "",
    'Buyout Hours':                0,
    'Job Name':                    "",
    'PersonalCalendarId':          "",
    'ItemId':                      0

This defines a working record that can be changed by changes to various controls, the overtime hours and holiday days are re-calculated and patched when the dates change etc. All in all there are 6 places this Global variable is Set() explicitly and over 20 places where it is Patched and Set.


This creates over 26 definition points for the types of each field in the record which are contiually parsed and validated to match correctly but the error warnings are only one level deep.


If I assign 'ItemId' a text value in one of those 26 places the type no longer matches all of the other definitions and I get the error

'The types of the specified context variables are incompatible with the types specified elsewhere'

As the Global Variables are still labeled as (experimental) I'll skip the fact it is being referenced as a context variable in the error, but it would be good to see consistent naming when it is no longer experimental.

It would appear that the Set() function is evaluated and because one of the types of one of the fields in the record does not match the Set() elsewhere it returnes an Error type instead of a Record type. Becaues type Error and Record are not compatible the error is shown based on that type inconsitency and not the actual cause of the problem.


Each of the 26 other places are also re-evaluated and validated against each other and now all show up the same error because they have the difference in type to the one that changed. This leaves no route to debug and trace the cause of the problem.

It means you have to manually check each of the 26 definitions to find the one with the difference to correct it.


Now I can understand that if I make a mistake in one of my definitions by defining the wrong type, and I get an error it is my fault and I should fix it. However coming back to the type coersion, if I do the following:


Patch(workingHolidayItem,{ 'Overtime Selected': ToggleControl.Value, } )

Notice, earlier I have set 'Overtime Selected' to false (a boolean) and then now Patched to reset it to ToggleContol.Value (also assumed to be a boolean) however sometimes I will still get the same type error as before even though the two values I would assume to be boolean. The only thing I can surmise is that the ToggleControl.Value is being incorrectly coerced to the wrong type causing the error. Whatever the cause of the error it seems to be more prevelent when assigning values from controls rather than explicitly which is what leads me to thinking it is something to do with the controls inbuilt type coersion functions.



This, combined with the problem I desciribed in my earlier post means that each time I change any of the Set() definitions of the Gloabal Varibale, I have to find the problem, try to rectifiy it, save the app full of errors, close the app, re-open the app, check to see if the errors have gone away... repeat until thiere is no error.


I know I'm detailng a somewhat specific issue here but I have a feeling others may have similar issues as they move away from using collections with a single record to the Global Variable way of working. The docuimentation on Global Variables suggests it is better to use a Global veriable Record thatn a collection for situations like these so I would imagine others are going to start hitting this issue as apps become more complicated.


I'm guessing there is no specific way to resolve my problem apart from single Global Variables instead of a record Global Variable or re-writing everthing back to using a collection.


Any input anyone may have on this would be greatly appreciated as at the moment I am rather stuck as to what my best move forward is.


Level 10

Re: Patching global variables from input controls breaks type validation

Disappointed that no-one from the PowerApps team is joining in this conversation, but I have a feeling that they are getting ready to release a new version in the next few days.

Level 8

Re: Patching global variables from input controls breaks type validation

Additional:- After playing around with Set() and Patch()


It seems if I just Set() which abandons all prevoius reference to fileds in the Global Variable Record in dont have any problems.

If I Set(Patch()) a version of the Global Veriable Record back to its self thats when I start getting the errors.

Level 8

Re: Patching global variables from input controls breaks type validation

Thanks @Meneghino,


If that is the case I may just put my development on hold until then, it might be that my issues are already fixed in the update.

Level 10

Re: Patching global variables from input controls breaks type validation

I think unlikely that your issues will get fixed.  The one update I think is coming is in relation to being able to get 2000 records instead of just 500 in one call, not sure what else.

Level 8

Re: Patching global variables from input controls breaks type validation

Ah, ok.


I'll maybe spend a few more hours investigating but I have a feeling I may be in for re-writing everything back to using a collection.

It's a bit dissapointing really because the Global Variable makes it much easier to reference without doing the First(collectionName).Field all the time.


Nevermind, Thanks for the input and tagging in the devs, hopefully somenone may have a suggestion.

Level 10

Re: Patching global variables from input controls breaks type validation

I fully agree and myself use a record type global variable.  It is silly to have to do First(CollectionName).

Level 8

Re: Patching global variables from input controls breaks type validation

I have made a discovery in a slightly different direction.


One of the filds in the Global Variable I am setting is its self a Record Value containning user information.

It is specifically Patching this user record value that is causing my specific problem.


What I cant work out is why...

It is something to do with the Patch() function because it is not a problem to Set() the fieald to the same record multiple times.

However as soon as I try to Patch() the Record into the Global Variable Record thats when I have the error.


I have created a test app that demonstrates the specific issue and the difference between Patching and Setting.


Here's a link to it on my OneDrive


Bug Test.msapp

Helpful resources


Watch Sessions On Demand!

Continue your learning in our online communities.

Top Community Contributors for July 2019

Top Community Contributors for July 2019

Let's thank our top community contributors

Power Platform 2019 release wave 2 plan

Power Platform 2019 release wave 2 plan

Features releasing from October 2019 through March 2020


Power Platform World Tour

Coming to a city near you


PowerApps Community User Group Member Badge

Fill out a quick form to claim your user group badge now!


Join PowerApps User Group!!

Connect, share, and learn with your peers year-round


Dynamics 365 and Power Platform April 2019 Release notes

Features releasing from April 2019 through September 2019!

Users Online
Currently online: 182 members 5,370 guests
Please welcome our newest community members: