Tag Archives: Patch

road landscape art street

Direct Action Buttons in Power Apps

No. “Direct action” buttons aren’t a new feature or button type. It’s just a term I’ve used in conversations and sessions talking about Power Apps and more often than not SharePoint lists or Microsoft Lists.

The default experiences users see with Lists or wizard-created apps in Power Apps are to act on a record or item as a whole (see image below). This by itself is fine as it accounts for plenty of use cases. However, there are also times where users want to take a specific action on a record. For example, in the case of managing requests, users may want to take ownership of a request, quickly assign a priority, or close a request. These can be accomplished with buttons build specifically for those use cases.

Microsoft list item editing. Showing the item menu selecting the "Edit" option.
Default list editing

In the default experience, operating on items in a data source (List, or other) the “close request” activity requires both technical knowledge and business knowledge.

  • The technical knowledge they need looks something like: Find the item, open/edit the item, change the value for the specific field from one value to another, and close/save the item.
  • The business knowledge users need, at a minimum, is to change *which field* to *which value*.

You’d hope both of these activities would be intuitive, but in many cases they are not. In most cases the process and user experience can be improved – even a little bit. Enter “direct action” buttons.

What does a simple, typical example look like? How about this? In a work request list, setting a request priority with a button click:

Two records with buttons to set each item to “High Priority”.

Logically, the example image probably has its priorities messed up (please rescue the raccoon before mowing the grass), but it illustrates a user wanting to take specific changes to an individual item.

Patch Command

The above items are in a Power Apps gallery. So, the code – in the OnSelect formula for the button might look something like this:

Patch('Work Requests List’, LookUp('Work Requests List',ID=Parent.Selected.ID),
{Priority: { Value: "1 - Needs immediate" }})

The Patch command is the key here. The example above breaks down as follows:

  • Patch('Work Requests List’, – The data source being updated
  • LookUp('Work Requests List',ID=Parent.Selected.ID), – Identify the specific item in the data source to update.
  • {Priority: { Value: "1 - Needs immediate" }}) – Set the “Priority” field to this value

For a more detailed look at the Patch command, check out the reference links below.

Note: In an example where the user selects an item in a Data Table, the formula will be slightly different:

Patch('Work Requests List’, LookUp('Work Requests List',ID=DataTable1.Selected.ID),
{Status: { Value: "Closed" }})

Crawl, Walk, Run

Once you get started down this path, there are so many options for makers to fulfill business needs with these approaches.

Intake lists (a generic term for request lists of all types) often evolve over time. These lists might start simply where “closing” a request is literally changing a status field from “open” to “closed”. As these processes mature, closing a request might turn into something like:

  • Change a status field to “closed”
  • Store the name of the person that closed the request (in a field separate from the modifiedby field)
  • Capture the date/time the request was closed (in a field separate from the modified field)
  • Send a notification to someone about the ticket closing (send an email, post to a Teams channel, etc.)

While the requirements get more complicated, all of these tasks can still be dealt with using Power Apps formulas or other approaches.

Alternate – JSON

There are ways to create buttons and actions within the List interface using JSON to implement view and column formatting. This is, by some, billed as another “no-code” approach, though it is not in my opinion. It is, however, an approved approach within the platform.

You can look into these approaches here: Advanced formatting concepts

Bonus Footage

A few extra notes.

DisplayMode for button

You may have noticed in the image above that the button can show up as enabled or disabled. This is accomplished by setting the DisplayMode formula to something like this:

If(ThisItem.Priority.Value="1 - Needs immediate", DisplayMode.Disabled ,DisplayMode.Edit)

The formula roughly translates to: If the item is already set to high priority, disable the button. If not, enable the button.

Refresh as needed

I haven’t looked into the details of the mechanics behind how screens and data sources work, but sometimes the screen updates right away after a Patch, other times it doesn’t. So, try the Patch and see if the screen and controls update the way you want. If they do, great! If the data doesn’t update quickly, you could add a Refresh to your button to force the data to refresh.

The “trick” here is that the refresh isn’t of the controls, but of the data source:
Refresh(DataSource)

Ramblings

I’ve been trying to figure out why it’s taken me so long to get a post out. It’s not technically challenging. In fact, it’s quite simple from the Power Apps perspective. From an experienced maker or pro-dev perspective, creating buttons is second nature. Power Apps offers plenty of power and flexibility in this department.

I think I just wanted to give enough context for makers to understand that while the concept is simple, the potential and implications can be huge – both in the capabilities makers have and in the improved experience for users. For makers, using something like Patch is a next step after working with the default form and the Save/Cancel options that come with the default experiences offered by Lists and wizard-created Power Apps.

It’s not rocket science. But plenty of folks just haven’t gone here yet. After almost every session where I mention “direct action” buttons, people are super excited about the possibilities. When they figure it out – it opens up so many cool options. Just a small step of growing in the Power Platform.

References

Updates

Note: The Patch function does NOT bypass Microsoft (and SharePoint) Lists updating the Modified date and Modified By fields. These fields do get updated when the Patch function updates anything in the item/record.