Going back from a detail page should restore the dashboard exactly as it was left, not just the URL

What it is

After a user drills from the dashboard into a detail page, "going back" means more than returning to the previous URL—the dashboard's state at the moment they left (filters, time range, expanded panels, selected charts) is a worksite that needs restoring. If going back resets the dashboard to its defaults, the user must reapply every filter to resume the investigation, or face unfamiliar data they don't remember configuring. "Back" in its full sense means restoring the worksite, not returning to the starting point.

Why it happens

This is the other side of the same coin as filter context handoff: the outbound trip needs "carry it there," the return trip needs "bring it back." Technically, if filter state is serialized into the URL, the browser's history stack naturally preserves a snapshot of every state, and restoration on back is automatic; if state lives only in component memory, going back (especially via the browser's back button) reinitializes everything and the worksite is gone. The cognitive cost hits the investigation chain's continuity: the user picked up a lead on the detail page ("the anomaly concentrates on mobile"), and their next action after returning depends on the dashboard state they just left (comparing the mobile curve against other channels)—after a reset, they must rebuild that premise before acting, and every extra rebuild raises the odds the investigation is abandoned.

Where it stops holding

The browser's back button and the in-page back link may behave differently: the back button restores the URL from browser history (including filter parameters), while an in-page "Back" hardcoded to the dashboard's default URL discards context—both return entries must be semantically identical. With multiple tabs or long sessions, the user may hold several dashboard states at once; the restoration target must be the snapshot corresponding to the current detail page, not "whichever dashboard was open most recently." When a session times out or the login expires, state restoration must chain with re-authentication, or the user returns to a login page instead of their dashboard.

Applying it

• Write every dashboard state change (filter, range, panel) into the URL so the browser history stack becomes the snapshot sequence naturally.
• Use history.back() or a link to the previous full URL (with parameters) for the in-page back link; never hardcode the dashboard's default address.
• Provide breadcrumbs on deep detail pages (dashboard > section > detail) with each level clickable and state-carrying.
• Verification: set a non-default state on the dashboard, drill three levels deep, then return via both the browser's back button and the in-page link; check that each return reproduces the exact state at departure.

Related

• Same group: U7.08.1 An anomaly found on the dashboard needs a next station toward explanation · U7.08.2 Jumping to a detail page must carry the current filter context · U7.08.4 A dashboard without drill-down paths can surface problems but not locate them · U7.08.5 Drillable elements need a clickable visual cue
• Nearby: U7.06.3 Relative and absolute ranges suit different usage scenarios · U7.07.2 Reading order should match the decision order
• Search terms: state restoration · browser history · breadcrumb navigation