Power Apps Button Control With SharePoint Examples

I still remember the first time a client asked me to add “just one button” to their leave request app. That one button turned into approve, reject, save as draft, and a resubmit action — all on the same screen. That’s when I really learned how much power a simple Button control carries in Power Apps, especially when it’s talking to a SharePoint list behind the scenes.

The Button is one of the first controls every Power Apps developer touches, but most people only ever use it for SubmitForm(). Once you connect it to SharePoint data with Power Fx formulas like Patch, Navigate, and Notify, it becomes the engine that drives almost every action in your app — creating records, updating statuses, deleting rows, and moving between screens.

In this guide, I’ll walk you through everything you need to know about the Button control in a Canvas app connected to SharePoint, using a real-world issue tracker app as our example throughout, with formulas you can copy straight into your own app.

What Is the Button Control in Power Apps?

The Button control is a clickable UI element in Canvas apps that runs a formula whenever a user taps or clicks it. That formula lives in the OnSelect property, and it can do almost anything — write data to SharePoint, navigate screens, show a confirmation message, or trigger a Power Automate flow.

Unlike a Form control, which is designed around collecting and submitting a full record, a Button is action-based. You decide exactly what happens, in exactly what order, using Power Fx formulas chained together with semicolons. This is what makes buttons so flexible — and also where I’ve seen beginners get stuck, because there’s no “default” behavior to fall back on.

If you’re just getting started, it helps to first know how to build an app in Power Apps and create a Canvas app from a SharePoint list, since every example below assumes your app is already connected to a SharePoint data source.

Setting Up Your Example: A Simple Issue Tracker

To keep things practical, I’ll use one SharePoint list called Issue Tracker throughout this article, with these columns:

• Title (single line of text) — issue name
• Description (multiple lines of text)
• Status (choice: New, In Progress, Resolved)
• Priority (choice: Low, Medium, High)
• Assigned To (person field)

We’ll build a screen with a Gallery showing all issues, an Edit form, and several Button controls to handle saving, deleting, and navigating.

If you haven’t connected your gallery to SharePoint yet, check out displaying a SharePoint list in a Power Apps gallery first — it sets up the foundation this article builds on.

Adding a Button and Connecting It to SharePoint

1. Go to Insert > Button on the ribbon and drop it onto your screen.
2. Rename it something meaningful in the Tree view — I always rename buttons like btnSaveIssue or btnDeleteIssue instead of leaving the default Button1. It saves so much confusion later when your app has 20 buttons.
3. Select the button and open the OnSelect property in the formula bar. This is where all the logic goes.
4. Change the Text property to something clear, like "Save Issue".

That’s the basic setup. Now let’s look at the formulas that make it actually do something with SharePoint.

Example 1: Save a Record Using SubmitForm

If your screen has an Edit form control (let’s call it EditForm1) connected to the IssueTracker list, the simplest save button uses:

SubmitForm(Form1)

This tells Power Apps to validate the form’s fields and push whatever the user entered into SharePoint — either creating a new item or updating an existing one, depending on the form’s Item property.

I usually pair this with the form’s OnSuccess property to show confirmation and reset the screen:

Notify("Issue saved successfully!", NotificationType.Success);
Navigate(BrowseScreen)

Pro Tip: I’ve found that relying only on SubmitForm works fine for simple forms, but it can silently fail if a required field is blank. Always check the form’s Error and ErrorKind properties, or better, add field-level validation before the user even clicks save. See Power Apps form field validation on submit for a full walkthrough.

Example 2: Save a Record Using Patch (Without a Form)

Forms are great, but sometimes you want more control — maybe you’re saving data straight from a Gallery, or you’re combining multiple Text input controls instead of using a full form. That’s where Patch comes in.

On your btnSaveIssue button, use:

Patch(
    'Issue Tracker',
    Defaults('Issue Tracker'),
    {
        Title: txtTitle.Text,
        Description: txtDescription.Text,
        Status: { Value: "New" },
        Priority:drpPriority.Selected
    }
);
Notify("New issue created!", NotificationType.Success);
Reset(txtTitle);
Reset(txtDescription)

Let’s break this down:

• Patch(IssueTracker, Defaults(IssueTracker), {...}) creates a brand-new record because Defaults() returns a blank template for the list.
• { Value: "New" } is how you set a Choice column in SharePoint — it needs the Value property, not just plain text.
• drpPriority.Selected.Value pulls the selected option from a Dropdown control connected to the same choice field.
• Reset() clears the input controls so the screen is ready for the next entry.

This same Patch pattern is exactly what you’d use to add an item to a SharePoint list from any screen, not just a form-based one.

Example 3: Update an Existing Record

To update instead of create, swap Defaults(IssueTracker) for the specific record you’re editing — usually Gallery1.Selected or ThisItem if the button lives inside a gallery template:

Patch(
    'Issue Tracker',
    Gallery1.Selected,
    {
        Status: { Value: "Resolved" }
    }
);
Notify("Issue marked as resolved", NotificationType.Success)

This is a pattern I use constantly — a one-tap “Resolve” button right inside the gallery, next to each issue. No need to open a form at all. For a deeper look at this exact scenario, see updating a SharePoint list item using the Power Apps Patch function.

Pro Tip: In my experience, the most common error here is "The requested operation is invalid" or a blank Title error, usually because the Title column wasn’t included in the Patch. Since Title is often required in SharePoint, always include it even on updates, or check the article on the network error when using Patch — Title is required if you hit this exact wall.

Example 4: Delete a Record on Button Click

Add a delete button inside your gallery or on a detail screen:

Remove('Issue Tracker', ThisItem);
Notify("Issue deleted", NotificationType.Warning)

ThisItem refers to the record in the current gallery row. On a standalone screen, use Gallery1.Selected instead. I always add a confirmation step before delete buttons run, because one accidental tap can wipe out real data:

If(
    Confirm.Value = true,
    Remove('Issue Tracker', ThisItem);
    Notify("Issue deleted", NotificationType.Warning)
)

You’d toggle Confirm.Value using a confirmation dialog or a simple Yes/No popup built with a container. If you want to explore layered popups, Power Apps container control is worth a look.

Example 5: Navigate Between Screens

Buttons aren’t just for data — they’re also your app’s navigation system. On your Gallery screen, an “Add New Issue” button typically does:

Navigate(DetailsScreen, ScreenTransition.Fade, { EditItem: Blank() })

And on a gallery item’s “Edit” button:

Navigate(DetailsScreen, ScreenTransition.Fade, { EditItem: ThisItem })

I pass the record as a context variable (EditItem) so the details screen knows whether it’s creating a new issue or editing an existing one. Then the form’s Item property becomes EditItem, and Defaults(IssueTracker) gets used only If(IsBlank(EditItem.ID), ...).

For more navigation patterns, including passing multiple parameters between screens, check out the Navigate function in Power Apps and creating a navigation menu in Power Apps.

Example 6: Disabling a Button Based on Conditions

A button doesn’t always need to be clickable. On the Save button, I often lock it down until required fields are filled:

DisplayMode = If(
    IsBlank(txtTitle.Text) || IsBlank(drpPriority.Selected.Value),
    DisplayMode.Disabled,
    DisplayMode.Edit
)

This uses IsBlank() to check for missing input and the button’s DisplayMode property to grey it out. It’s a small touch, but it stops a lot of “why didn’t my save work” support tickets before they happen. Read more in setting a button to disabled in Power Apps and Power Apps DisplayMode.

Example 7: Running Multiple Actions With Concurrent()

Sometimes a button needs to write to more than one place — say, update the issue and log an activity record at the same time. Instead of chaining Patch calls one after another (which runs them sequentially and slows the app down), use:

Concurrent(
    Patch('Issue Tracker', ThisItem, { Status: { Value: "In Progress" } }),
    Patch(ActivityLog, Defaults(ActivityLog), { LogText: "Status changed", RelatedIssue: ThisItem.Title })
)

Concurrent() runs both Patch operations in parallel, which noticeably speeds things up when a button triggers multiple SharePoint writes. See the full explanation in Concurrent function in Power Apps.

Building a Responsive Button Layout

Since most teams now open Canvas apps on phones, tablets, and desktops, I always design button rows so they resize properly instead of hard-coding pixel widths. A responsive pattern I use often on an action bar with three buttons (Save, Delete, Cancel):

• Set each button’s Width to (Parent.Width - 40) / 3 so three buttons always share the available screen width evenly, with margin.
• Set X using Self.Width * Index logic, or simpler, use a horizontal container with “Layout: Horizontal” and “Fill portions” so Power Apps handles spacing automatically for you across screen sizes.
• Keep the button Height relative to Parent.Height * 0.06 so it scales sensibly on both a phone and a widescreen tablet.

This way, the same issue tracker app looks right whether it’s opened in Power Apps Mobile or on a laptop browser — no clipped buttons, no awkward overlap.

Things to Keep in Mind

• Choice columns always need a Value wrapper. Writing Status: "New" instead of Status: { Value: "New" } is one of the most common Patch errors I see with SharePoint choice fields.
• Delegation limits still apply inside buttons. If your button’s formula filters a large SharePoint list, keep an eye on Power Apps delegation warnings — non-delegable functions inside a button can silently process only the first 500 or 2,000 records.
• Don’t overload OnSelect with too much logic. If a button’s formula runs past five or six lines, I usually move the logic into a named formula or a Power Automate flow for readability and easier debugging.
• Use Notify() generously. Users need feedback after every action — save, delete, or update — otherwise they’ll click the same button multiple times, creating duplicate records.
• Test with real SharePoint permissions. A button that works fine for you as site owner may fail silently for a user with only Contribute access, especially on delete actions.
• Rename every button control. Default names like Button3 make troubleshooting formulas painful once your app grows past a couple of screens.

Frequently Asked Questions

We covered how to connect the Button control to SharePoint for saving, updating, deleting, and navigating, using real Power Fx formulas from a working issue tracker app. My best advice is to start simple — one button, one clear action — then layer in validation, disabled states, and Concurrent calls as your app grows. I hope you found this article helpful.

You may also like the following tutorials:

• Create CRUD Operations Using Power Apps
• Power Apps Gallery Control: A Complete Guide
• Create a Form in Power Apps
• Power Apps Collection Using a SharePoint List
• Power Apps Dropdown Control With SharePoint