The formula is you have written that either launch a new app URL (replacing the current session) if the ApproverID parameter exists, or otherwise it navigates to the 'Approver Dashboard' screen . For deep linking scenarios - good and correct .
However, on mobile devices, the issue where the back button does not navigate as expected often happens because:
- The
Launch function with LaunchTarget.Replace replaces the current app session! Hence, no navigation history to go back to!
- The mobile app or browser may not handle the navigation stack the same way as desktop browsers.
- The
Navigate function works only within the current app session and screen stack.
Avoid using Launch with LaunchTarget.Replace for back navigation on mobile
Instead, consider navigating within the app using Navigate() to a known screen or home screen, so the navigation stack is maintained.
Use conditional navigation with fallback
If(
!IsBlank(Param("ApproverID")),
Navigate('Approver Dashboard', ScreenTransition.None),
Navigate('Approver Dashboard', ScreenTransition.None)
)
This way, you avoid launching a new app session and keep navigation internal.
If(
!IsBlank(Param("ApproverID")),
Launch(
"https://apps.powerapps.com/play/e/default-XXXXXXXXXXXXXXXX/a/YYYYYYYYYYYYYYYYYYYYYYYYYYYY",
{},
LaunchTarget.Replace
),
Navigate('Approver Dashboard', ScreenTransition.None)
)
Also:
- Please consider adding a query parameter to indicate the return screen - if you must launch a new app URL. Then, on app start, detect this parameter and navigate accordingly.
- Explicit in-app back or close button is always good to deep-linked screen that uses
Navigate/Back to control navigation reliably.
- To confirm navigation behavior, it is always good to Test on actual devices and consider adding logging or visual indicators .
I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!
