Signing in should land you where you were going
Open a link to a report, sign in, and the office dropped you on the dashboard. The address bar lied while the form showed. Both fixed; the link now lands.
Somebody sends you a link to the stock report. You open it, you are not signed in, so the office shows the sign-in form. You sign in. You land on the dashboard, and the report you came for is a tap or two away if you remember what it was called. Every app that has ever had a sign-in screen has had this fault at some point, and the tester found ours twice over in one row.
The second half of the row was about the address bar. While the sign-in form was showing, the bar still read the page you had asked for, as if you were on it. The app had two ways of arriving at the form: a session that had expired moved the address to the sign-in page, and a visitor with no session at all did not. One path remembered to update the bar and the other never had.
Write it down, then come back to it
Both halves are one fix. When the app decides a visitor has to sign in, it writes down where they were headed, the path and its query string, in the browser’s session storage, and then moves the address to the sign-in page so the bar tells the truth. When the sign-in succeeds, it reads that note back, clears it, and sends the browser there. If the note is missing or names something that is not an app page, the dashboard is the fallback, as before. A link to the sign-in page itself is never a destination, so signing in from it cannot loop you back to the form.
There is a rule behind this we apply across the product: a notification or a shared link opens the exact thing it refers to, never the home screen. A receipt link opens the receipt, a kitchen link opens the ticket, and a link to a report opens the report, with the sign-in form as a step on the way rather than a detour that forgets where you were going.
It was driven in a browser against the deployed build: open a report path cold, see the form with the bar reading the sign-in page, sign in, and arrive on the report. The expired-session path was checked the same way, since it was the one that already half worked and was the easiest to break by accident.