Navigating between screens

1. Navigating between screens

Welcome back. In this video we'll look at wiring screens together so users can tap a row, see its details, and navigate back.

2. From one screen to many

A real help-desk app needs at least three screens: a browse screen for the list, a detail screen for one ticket's full info, and an edit screen with a form. Three Power Fx functions move users between them, and we'll meet each one next.

3. Navigate()

The simplest navigation function is Navigate(). Pass the screen you want to go to and Power Apps takes the user there. You usually wire it to a Button's OnSelect or a Gallery's OnSelect. Drop Navigate(DetailScreen) on the gallery row, click any ticket, and the user lands on the detail screen. There are no animation arguments and no awkward routing, just one function call for one transition.

4. Set(), carrying data across

Navigate alone is not enough. The detail screen has to know which ticket the user picked. That's where Set comes back in. On the gallery's OnSelect you set a variable to the current row and then navigate, chaining the two with a semicolon, the way the slide shows. That variable, selectedTicket, is now an app-wide value holding the row the user tapped, so the detail screen can read its title, its priority, anything it needs. It's the same Set you met in the first chapter, just doing more work.

5. Back()

Returning is even simpler with Back(), which takes no arguments. Power Apps tracks the navigation stack and Back() pops the most recent entry. Add a back-arrow icon to the detail screen's top-left, set its OnSelect to Back(), and the user is back on the gallery with the gallery's filter and scroll position preserved. It's a tiny function for a big win, because users hate apps that lose their state.

6. Variable scope, where does it belong?

A common question is where a value should live. There are four places to choose from. App.Formulas lets you declare app-wide constants, like isManager = false, available on every screen without calling Set(). For values that never change, App.Formulas is now preferred over setting them in App.OnStart. App.OnStart is still the right home for a state you change later, like a counter you initialize once at launch with Set(), and it's where the ClearCollect that loads your tickets lives. Screen.OnVisible runs every time a screen opens, perfect for refreshing a screen-specific value. A Button's or Gallery's OnSelect runs only on the user action. Get the scope right and your variables stay predictable.

7. Name your controls like a pro

There's one last habit to pick up before the exercises. Up to now we've used Power Apps' default names, Label1, Button2. That's fine when a screen has three controls. Multi-screen apps can have fifteen on a single screen, and Label7 tells you nothing. Adopt a tiny naming convention: lbl for Labels, btn for Buttons, gal for Galleries, and frm for Forms. So lblTicketTitle is obviously a Label, and the next person to open the Tree View, including future-you in two weeks, can scan it in seconds.

8. What you'll build

In the exercises you'll wire a browse screen to a detail screen so tapping a row shows its full record, and a back-arrow returns the user to the gallery.

9. Let's practice!

Time to wire your two screens together.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.