Power Apps

Build a Parent-Child Power App with SharePoint Lists

Create a Power Apps master-detail form over two related SharePoint lists, save the parent first and handle lookup fields, delegation and partial failures.

LauraRogers214 · 29 January 2021 · Updated 24 August 2026 · 3 min read

A parent-child app stores one master record, such as an expense report, and several detail records, such as its line items. In SharePoint, use two lists and connect each child to its parent through a lookup column. Save the parent first because the child needs the parent's generated list ID.

Example list design

Create these lists:

Expense Reports

  • Title, single line of text
  • Employee, Person
  • ReportDate, Date
  • Status, Choice

Expense Lines

  • Title, single line of text
  • ExpenseReport, Lookup to Expense Reports
  • ExpenseDate, Date
  • Amount, Currency
  • Category, Choice

SharePoint display names and internal names can differ. Renaming a column later does not necessarily change its internal name. Inspect the field in Power Apps before writing a Patch formula.

The SharePoint lookup creates a useful relationship, but it does not turn the lists into a transactional relational database. Plan for partial saves and concurrent edits.

Load the selected parent and children

Set the parent gallery's Items to a delegable filter appropriate to the user's role. When a parent is selected:

Set(varParent, galReports.Selected)

Filter the child gallery by the lookup ID:

Filter(ExpenseLines, ExpenseReport.Id = varParent.ID)

Connector support for delegation changes by operation and field type. Check the formula for warnings against SharePoint and test beyond the local row limit. Microsoft's delegation overview explains why a formula can appear correct with a small list and omit records later.

Save a new parent with a form

Use an Edit form for the parent when possible. Forms handle common SharePoint field shapes and validation more safely than a large hand-written Patch.

Start a new record:

NewForm(frmReport);
Navigate(scrEditReport)

Submit it:

SubmitForm(frmReport)

Do not create child records immediately after SubmitForm in the same button formula. Submission is asynchronous. Use the form's OnSuccess property:

Set(varParent, frmReport.LastSubmit);
Navigate(scrEditLines)

Use OnFailure to show frmReport.Error in a controlled message and keep the user's input available for correction.

Create a child with Patch

Once varParent.ID exists, create a line:

IfError(
    Patch(
        ExpenseLines,
        Defaults(ExpenseLines),
        {
            Title: txtLineTitle.Text,
            ExpenseReport: {
                Id: varParent.ID,
                Value: varParent.Title
            },
            ExpenseDate: dpExpenseDate.SelectedDate,
            Amount: Value(txtAmount.Text),
            Category: ddCategory.Selected
        }
    ),
    Notify("The line was not saved. Check the values and try again.", NotificationType.Error)
)

Lookup and Choice record shapes vary with connector metadata and control type. Use the actual cards or generated form formulas as a reference. The Patch function documentation describes creating a record with Defaults, but it cannot determine your field shapes.

Edit and delete safely

Patch an existing line by using the selected source record as the base:

Patch(ExpenseLines, galLines.Selected, {Amount: Value(txtAmount.Text)})

Before deleting a parent, decide what happens to children. Do not assume SharePoint will remove them automatically. Either prevent deletion while child records exist, or run a controlled cleanup process with error reporting and an audit trail.

Permissions and security

Users need access to both lists. Item-level SharePoint settings can create confusing cases where a user sees the parent but not its children. Hiding a button in Power Apps is not authorisation.

Test with the actual permission groups and confirm create, read, update and delete separately. For stricter row ownership, richer relationships or transactional requirements, assess Dataverse rather than forcing SharePoint to behave like it.

Failure and recovery

The parent can save while a child fails. Make that state visible. Keep unsaved child input in a local collection, show which rows failed, and let the user retry. If the business requires all-or-nothing writes, a canvas app making separate SharePoint calls is not enough by itself.

Use Monitor to inspect connector calls and returned errors. A clean formula and one successful save do not prove concurrent edits, throttling or production permissions.

For more buildable master-detail patterns with data and recovery boundaries included, join the Power Apps Builders Space.

Sources