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. The starter app already has a gallery, filter, and search wired up, so you can focus on what's new.

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. We'll use three Power Fx functions that move users between those screens. We'll meet all three in the next four slides.

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. No animation arguments, no awkward routing, one function call, 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, Back(). 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. Tiny function, big UX win, users hate apps that lose their state.

6. Variable scope, where does it belong?

A common question is where a value should live. Three levels. 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 state you change later, like a counter you initialize once at launch with Set(). Screen.OnVisible runs every time a screen opens, perfect for refreshing a screen-specific value. And 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

One last habit 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, 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.