Updating PowerApps Screens and Forms Programmatically


Forms in PowerApps are the way to connect a part of the screen to a data source explicitly. Forms can be either be a view or an edit form. Strangely, these aren’t different display modes of the same control. Edit forms have different capabilities than display forms, so generally you want to use an edit form if you expect you may ever want to edit some of the data — so that you don’t have to recreate the form.


There are two kinds of variables inside your PowerApp. First, there are global variables, which are established with the Set() function. The second are screen-level context variables, which are either passed into the screen through the parameter of the Navigate() function or are established by use of the UpdateContext() function.

Data Cards

Forms are containers for a set of data cards. These data cards are the templates for the display of each of the individual fields from the data source. The wizard prompts you to select which fields you want to have on your form and the general layout. The importance is that each data card is associated to a field in the data source, so when the data field is updated, the display updates.

Text Fields

Before we continue with the discussion of forms, it’s important to note that the approach that we’re explaining here works just fine with regular text fields which are on the screen — even though they aren’t in a form. If you set a text field’s .Text property to the value of a field in an item, this will only be updated when you update the item. If you attempt to programmatically set the .Text property during runtime, your changes won’t be reflected on the screen. However, if you update the variable that the text field is bound to, it will update the text field for you automatically.

Creating Records

Creating a blank record in a PowerApp can be done by calling NewForm() when you have a form; however, doing this doesn’t allow you to set any starting data. In the case where you want to create records that are specific to the customer, but you don’t want the customer number to be in the form, you’re forced to precreate the record, then display it in the form.

Precreating a Record

To create the record, we’re going to use the Patch() function. This takes the data source, the item, and the updates. The data source is easy. It’s the same data source as we’re using for the form. The item is the potentially challenging part. We need to create an item with all the defaults for our data source. To do that, we call Defaults() with the parameter of our data source. This gets an item with all the defaults for the item. To that we add anything that we need to initialize the record. For instance, let’s call our data source “Sample” and assume we need to initialize a field called “Title” to the current date. The code looks like this:

Selecting the Precreated Record

With the new record, we need to get it to display on the form or as a part of the screen. To do this, we update the variable that we have our form set to. In our example, it happens that Patch() returns our updated record, so we can put that inside of a Set() for a global variable or a UpdateContext() for a context variable. If we were to call our variable SampleItem as a global variable, the code would look like:

Updating Records

That’s fine for new records, but how do you make an update to an existing record? It’s the same process — except instead of specifying the defaults for the patch, you specify the existing variable. It looks like this:

That’s a Wrap

It may not be the way you’d typically think about the process in a more traditional form building tool — but it’s effective.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store