Power Apps

Power Apps Beginner's Guide: Build and Release Your First Canvas App

Build a small canvas app from a real data source, then test its formulas, delegation, permissions, errors, save, publish and sharing boundaries.

Collab365 Team · 30 March 2026 · Updated 24 August 2026 · 3 min read

Your first useful Power App should solve one small process, use one understood data source and have one person responsible for it. Build a canvas app with a list, gallery, form and confirmation path. Then test it as an ordinary user before you publish it.

Prerequisites

You need access to Power Apps, an environment where you may create an app, and permission to the chosen data source. Your Power Apps and connector rights depend on assigned licences and tenant policy.

For this example, use a Microsoft List named Requests with these columns:

Column Type
Title Single line of text
RequestStatus Choice: New, In progress, Closed
RequestDetails Multiple lines of text

Avoid confidential production data while learning.

1. Create the canvas app

In the maker portal, choose the correct environment. Select Create, start with a blank canvas app, choose a layout and give it a specific name.

In Power Apps Studio, open Data, add the SharePoint connector and choose the Requests list. The connection uses a user identity, so later users also need appropriate access to the list.

2. Add a browse screen

Insert a vertical gallery and set its Items property:

SortByColumns(Requests, "Modified", SortOrder.Descending)

Display ThisItem.Title and ThisItem.RequestStatus.Value. If Power Apps shows a delegation warning after you change this expression, stop and check the delegation documentation. A formula working against ten rows does not prove that it returns all relevant production rows.

3. Add a form

Insert an edit form named frmRequest. Set:

DataSource = Requests
Item = galRequests.Selected

Add the three fields. For a new-record button, use:

NewForm(frmRequest);
Navigate(scrEdit)

For an edit button, use EditForm(frmRequest) before navigation.

4. Submit with an error path

Set the save button's OnSelect to:

SubmitForm(frmRequest)

Set the form's OnSuccess:

Notify("Request saved", NotificationType.Success);
Back()

Set OnFailure:

Notify(
    Coalesce(frmRequest.Error, "The request could not be saved."),
    NotificationType.Error
)

SubmitForm validates required fields and runs asynchronously. Put success navigation in OnSuccess, not immediately after SubmitForm, so a failed submit does not send the user away from their unsaved form.

5. Test the failure cases

Preview the app and test create and edit. Then test:

  • a required field left blank;
  • an ordinary user with list access;
  • a user without list access;
  • a connector or network failure where possible;
  • enough list rows to expose delegation mistakes;
  • keyboard navigation and readable labels.

Use App checker and Monitor to investigate errors. Remove temporary diagnostic controls and do not log sensitive form values.

6. Save, publish and share

Save with version notes. Saving does not update what users run. Publish the tested version, then share the app with users or an appropriate security group.

Sharing the app does not share its data automatically. Give users only the SharePoint permissions they need and test again with their real role. Record an owner and support route so the app does not depend on one maker's account.

What this build proves

It proves that you can connect a small canvas app to a list and use a form safely. It does not prove that SharePoint is the right data platform for a larger relational process, that every formula delegates or that the design meets an organisation's security and licensing requirements.

If you want help checking the first app before colleagues depend on it, join the Power Apps Builders Space.

Sources