Remembering Where They Were
The web app can return a user to where they were rather than to the home page.
Where to find it
Architect Panel → Configuration:
- Site Settings — the Progressive Web App and Service Workers option groups
What is actually recorded
For each page a user visits: the address, the query parameters, any posted form values, and the scroll position — against that user’s identity.
Because query parameters are included, filters and selections that live in the URL come back with the page. Because scroll position is included, a long list returns where the user was reading.
How it is replayed
On reopening, the platform takes the user’s recorded steps from their most recent visit to the home page onwards, and replays them. So the app rebuilds the path they were on rather than jumping to a single page out of context.
That is why the home page setting matters here — it is the anchor the replay starts from.
What it does not remember
Unsaved form input that was never submitted. A half-completed form is not recovered, and anybody who has been told otherwise will be disappointed at the worst moment.
If losing work is a real risk in your application, that needs solving in the form, not here.
When it is clearly right
- Long forms and processes spanning several pages.
- Field use, where the app is interrupted constantly.
- Long lists, where losing the scroll position means finding your place again.
When to leave it off
- Shared devices. Restoring one person’s position on a shared tablet shows the next person where they were.
- Sensitive content, where reopening onto a record is not appropriate.
- Anything where a fresh start is correct — a till, a kiosk, a check-in screen.
It stores what people did
The recorded state includes addresses and posted values, which is a record of activity. Consider retention, and consider what it holds before enabling it on anything sensitive.
Give people a way home
Restoring to a deep page is helpful and occasionally disorienting. A visible route back to the home page turns a confusing restore into a minor one.
Test the interruption
Use the app, close it mid-task, reopen it. That is the experience the setting exists for, and it is the only way to know whether it feels helpful or strange in your application.
Worked example
A field app keeps state on, because engineers are interrupted constantly and returning to the middle of a job sheet saves real time. The same organisation’s reception check-in screen has it off, because each visitor should start fresh.
Recommendations
- On for personal devices, off for shared ones.
- Do not promise form recovery — it is not stored.
- Consider retention of the recorded activity.
- Test by interrupting a real task.