Power Apps LastSubmit: Get the Submitted Record and New ID After SubmitForm

Someone saves a request in your app, and the next screen needs that request’s new ID. SharePoint creates the ID on the server, so the form doesn’t know it until the save finishes.

In this tutorial, we’ll use Power Apps LastSubmit to read the record a form just saved, including its new ID. We’ll build the demo form, read LastSubmit in OnSuccess, handle OnFailure, and get the ID after Patch when there’s no form.

Quick answer: frmRequest.LastSubmit returns the last record the Edit form saved, with server-generated columns such as ID. Read it in the form’s OnSuccess property, for example Set(gblLastId, frmRequest.LastSubmit.ID), because it’s blank before the first save and after NewForm.

// frmRequest.OnSuccess
Notify("Request " & frmRequest.LastSubmit.ID & " saved");
Set(gblLastId, frmRequest.LastSubmit.ID)

What You Need Before You Start

LastSubmit is a property of the Edit form control, so you need a form that saves to a data source. If you’ve never built one, our guide to submit a Power Apps form to a SharePoint list covers the basics. Here’s our setup:

• A Microsoft 365 account that can create canvas apps in Power Apps
• A SharePoint list to save to. Ours is Service Requests on the SPGuides site, with Title (required), Status, Priority, Requester, DueDate and RequestedOnText
• Edit permission on that list, because the form creates new items

A data source is where the app reads and writes its records. Each row in it is a record, and LastSubmit holds one record.

Build the Demo App Step by Step

1. Check the list. Our Service Requests list already holds the demo data. SharePoint creates the ID column for every new item:

2. Open the maker portal. Go to make.powerapps.com, stay on Home and select Start with design:

3. Start a blank canvas app. On the Create an app page, select Create from blank:

4. Pick the layout. Choose Tablet. Power Apps Studio, the app editor, opens with a blank screen:

5. Add SharePoint. Select Add data, search for SharePoint and pick the SharePoint connector:

6. Connect to the site. Paste the site URL and select Connect:

7. Choose the list. Check Service Requests and select Connect:

8. Insert an Edit form. Open Insert and select Edit form. It’s in the Popular group:

9. Pick the data source. The form asks for a data source right away. Select Service Requests:

Studio fills in the fields for you. We renamed the form frmRequest and kept six fields. Its DataSource property now reads ‘Service Requests’:

10. Set the form to New mode. In the Properties pane on the right, set Default mode to New. New mode creates an item instead of editing one:

Every formula goes in the formula bar at the top. Pick the property in the dropdown left of fx, then type. To test, select Play at the top right, or hold Alt and click a button. Press Ctrl+S to save.

Step 1: Add a Submit Button With SubmitForm

Insert a button, set its Text to Submit request and its OnSelect to SubmitForm. Our Power Apps tutorials hub has more on buttons and behavior formulas:

SubmitForm(frmRequest)

SubmitForm checks required fields first. If they pass, it sends the record to SharePoint and then runs the form’s OnSuccess. If they don’t, it runs OnFailure instead.

Step 2: Read LastSubmit in the Form’s OnSuccess

Select the form, open the property dropdown and choose OnSuccess. This is where Microsoft documents that LastSubmit is ready:

Type this formula. Notify shows a banner, which our Power Apps Notify function post covers. Set copies the ID into a global variable:

Notify("Request " & frmRequest.LastSubmit.ID & " saved");
Set(gblLastId, frmRequest.LastSubmit.ID)

Why a variable? LastSubmit belongs to the form, and the form can lose it, as you’ll see below. A global variable keeps the ID for every screen. Our post on global vs context variables in Power Apps explains the difference.

You can also send the user to a confirmation screen from OnSuccess. Add a Navigate call after Set, as shown in our guide to navigate between screens in Power Apps.

Step 3: Test in Preview and Check What LastSubmit Holds

We added labels next to the form that show IsBlank(frmRequest.LastSubmit), its ID, Title and Status, the form mode and gblLastId. Before any save, LastSubmit is empty:

We typed LastSubmit demo – Printer jam 2026-10-18 as the Title, Megan Bowen as the Requester, and selected Submit request. SharePoint created item 621:

Three details are worth noticing. LastSubmit.ID showed 621, a value the form never had. LastSubmit.Status showed New, even though we left Status blank, because SharePoint applied the column default and LastSubmit returned it.

The form also switched from New to Edit mode and showed “No item to display”, since its Item property points at nothing. That’s normal after a New-mode save.

A second save, LastSubmit demo – VPN reset 2026-10-18, created item 623. The OnSuccess banner read it straight from LastSubmit:

Both items are in the SharePoint list, along with the Patch test from Step 5:

Step 4: Handle a Failed Save With OnFailure

Set the form’s OnFailure property so users know a save didn’t work. We also show LastSubmit there to prove what it holds:

Notify("Save failed. LastSubmit.ID is still: " & frmRequest.LastSubmit.ID, NotificationType.Error)

We selected Submit request with an empty Title. The Title card said “Title is required.”, OnFailure showed the red banner, and no item was created. A label set to frmRequest.Error showed the reason:

LastSubmit stayed blank because nothing was saved. After a successful save, a later failure doesn’t replace it, since it only ever holds the last successful record.

Step 5: Get the ID After Patch (No Form)

LastSubmit only exists on an Edit form. When you create items with Patch, use its return value instead. Patch returns the record it created, including the new ID. Our Power Apps Patch function guide covers more patterns:

Set(varNew, Patch('Service Requests',
    Defaults('Service Requests'),
    {Title: "LastSubmit demo - Patch 2026-10-18"}))

A label with varNew.ID showed 622 after one click. LastSubmit stayed blank, because Patch doesn’t go through the form:

That’s the best way to get the ID after Patch: wrap Patch in Set and read the field from the variable. Don’t follow it with a lookup for the newest item.

LastSubmit vs Patch Return Value: Cheat Sheet

Question	Edit form + LastSubmit	Patch return value
How you save	SubmitForm(frmRequest)	Set(varNew, Patch(...))
Where to read the ID	OnSuccess: frmRequest.LastSubmit.ID	Right after the call: varNew.ID
Before the first save	Blank (IsBlank = true)	Blank variable
Server defaults included	Yes (Status came back New)	Yes (item 622 got New too)
Cleared by	NewForm (tested)	Only when you Set it again
On a failed save	Unchanged; OnFailure runs	Use IfError around Patch

Why Is Power Apps LastSubmit Blank?

Usually because something switched the form back to New mode. After saving item 621, we selected a New form button that runs NewForm(frmRequest). LastSubmit was blank again, but gblLastId still said 621:

So if a confirmation screen or a Reset button calls NewForm before you read LastSubmit, you’ll get nothing. Copy the ID into a variable in OnSuccess first, and read the variable everywhere else.

The other common cause is reading LastSubmit before any save in the session, or from a form that saved through Patch rather than SubmitForm. It’s an in-app property, not a query, so it doesn’t remember earlier sessions.

Common Mistakes to Avoid

• Using Last(‘Service Requests’).ID to find the new item. Last isn’t delegable, so on a big list it only sees the first 500 rows (2,000 at most) and returns the wrong ID. For a per-user lookup, see how to get the last item ID for the current user.
• Reading LastSubmit in the button’s OnSelect. Microsoft documents the value in OnSuccess. Put follow-up Patch, Navigate or Notify calls there, not after SubmitForm on the same button.
• Calling NewForm before you store the ID. We tested it: NewForm clears LastSubmit. Set a variable first.
• Expecting LastSubmit on a Display form or after Patch. It’s an Edit form property and only changes when SubmitForm succeeds.
• Hiding failures. Leave OnFailure empty and users think the save worked. Show frmRequest.Error in a label or a Notify.

If you build forms like this every week, our Power Apps training course covers forms, variables and SharePoint on real projects.

Next Steps

Add the OnSuccess pattern to one form you already have, then test a failed save on purpose. Next, fill the form’s choice fields from SharePoint with our Power Apps Choices function walkthrough.

We’d read one of these next if you’re building SharePoint forms in Power Apps:

• How to Customize SharePoint List Forms with Power Apps?
• How to Use Power Apps Modern Form Control?
• Show Hide Power Apps Form Based On Gallery Selected Item
• Save Power Apps Form Attachments to SharePoint List Using Power Automate

Frequently Asked Questions