[GH-ISSUE #5408] [Feature Request]: Persist User Bookmarks to the User Account (Cross-Browser / Cross-Device) #2605

New issue

Open

opened 2026-03-02 13:53:42 +03:00 by kerem · 1 comment

kerem commented

2026-03-02 13:53:42 +03:00

Owner

Originally created by @Lowell-Syncrety on GitHub (Feb 19, 2026).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/5408

Please confirm:

I have searched existing feature requests (open and closed) and found no duplicates.
**me or my organization is currently an active sponsor of the product at the $99,- level.

Problem Statement

Currently, user bookmarks appear to be stored only in the local browser cache/storage, meaning they do not follow the user across browsers or devices and can be lost if the browser cache/storage is cleared. This is inconsistent with normal expectations for a modern web app, especially an MSP admin tool where technicians routinely switch devices, use multiple browsers, or operate on shared/locked-down machines.

I love the Bookmarks feature and rely on it heavily as some menu options are in unexpected places (I get why the organization is set up the way it is generally, but it can take some getting used to).

(Context: this behaviour has been discussed/confirmed in the community; additionally, CIPP documentation already notes that clearing cache removes “personal settings,” which aligns with bookmarks being client-side state.)
https://docs.cipp.app/user-documentation/cipp/settings

Related UX/documentation gap:

The Bookmarks documentation page explains how to add/use bookmarks, but does not warn that bookmarks may be browser-local and can disappear when cache/storage is cleared or when moving to a different browser/device.
https://docs.cipp.app/user-documentation/shared-features/menu-bar/bookmarks

The Application Settings documentation explicitly states that clearing cached information “will also remove any personal settings such as the selected theme,” but it does not clearly call out bookmarks, which are a high-impact “personal setting” if they’re stored client-side.
https://docs.cipp.app/user-documentation/cipp/settings

Benefits for MSPs

Consistency across environments: Technicians often work from multiple endpoints (office, home, client site, jump boxes). Bookmarks should be part of the user’s CIPP profile, not tied to one browser profile on one machine.
Reduced productivity loss: Losing curated navigation shortcuts after cache clears (common in security-hardened environments) forces rework and slows down repeat tasks.
Improved onboarding + standardization: When user bookmarks persist, it becomes feasible to train staff to rely on them without fear they’ll vanish unexpectedly. (This also complements the broader “bookmarks as workflow” concept in CIPP.)
Fewer “is this broken?” support moments: A silent “bookmarks reset” experience reads like a defect even if it’s “by design,” generating confusion and avoidable support cycles.

Value or Importance

High value / quality-of-life + UX correctness.

This is foundational application behaviour: user personalization should be identity-backed (stored server-side and loaded per user session), not reliant on client cache/storage. Losing bookmarks when switching browsers/devices or clearing cache undermines trust in the UI and discourages adoption of the feature.

Acceptance criteria (suggested):

Bookmarks are stored server-side and associated to the authenticated user (or user profile settings).
Bookmarks persist across:
- different browsers (Edge/Chrome/Firefox)
- different machines
- cleared browser cache/storage
Optional: include a migration path to import existing client-side bookmarks into the persisted profile on first load.

Documentation improvement (at least until new feature implemented):

Update the Bookmarks doc to explicitly state current persistence behaviour and/or remove the caveat once bookmarks are account-persistent.
Update the Application Settings/Cache doc to clearly list that clearing cache removes bookmarks if bookmarks remain client-side, because right now it only gives an example (“theme”) and doesn’t explicitly mention bookmarks.

PowerShell Commands (Optional)

No response

Originally created by @Lowell-Syncrety on GitHub (Feb 19, 2026). Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/5408 ### Please confirm: - [x] **I have searched existing feature requests** (open and closed) and found no duplicates. - [x] **me or my organization is currently an active sponsor of the product at the $99,- level. ### Problem Statement Currently, user bookmarks appear to be stored only in the local browser cache/storage, meaning they do not follow the user across browsers or devices and can be lost if the browser cache/storage is cleared. This is inconsistent with normal expectations for a modern web app, especially an MSP admin tool where technicians routinely switch devices, use multiple browsers, or operate on shared/locked-down machines. I love the Bookmarks feature and rely on it heavily as some menu options are in unexpected places (I get why the organization is set up the way it is generally, but it can take some getting used to). (Context: this behaviour has been discussed/confirmed in the community; additionally, CIPP documentation already notes that clearing cache removes “personal settings,” which aligns with bookmarks being client-side state.) https://docs.cipp.app/user-documentation/cipp/settings **Related UX/documentation gap:** The Bookmarks documentation page explains how to add/use bookmarks, but does not warn that bookmarks may be browser-local and can disappear when cache/storage is cleared or when moving to a different browser/device. https://docs.cipp.app/user-documentation/shared-features/menu-bar/bookmarks The Application Settings documentation explicitly states that clearing cached information “will also remove any personal settings such as the selected theme,” but it does not clearly call out bookmarks, which are a high-impact “personal setting” if they’re stored client-side. https://docs.cipp.app/user-documentation/cipp/settings ### Benefits for MSPs - **Consistency across environments**: Technicians often work from multiple endpoints (office, home, client site, jump boxes). Bookmarks should be part of the user’s CIPP profile, not tied to one browser profile on one machine. - **Reduced productivity loss**: Losing curated navigation shortcuts after cache clears (common in security-hardened environments) forces rework and slows down repeat tasks. - **Improved onboarding + standardization**: When user bookmarks persist, it becomes feasible to train staff to rely on them without fear they’ll vanish unexpectedly. (This also complements the broader “bookmarks as workflow” concept in CIPP.) - **Fewer “is this broken?” support moments**: A silent “bookmarks reset” experience reads like a defect even if it’s “by design,” generating confusion and avoidable support cycles. ### Value or Importance ### High value / quality-of-life + UX correctness. This is foundational application behaviour: user personalization should be identity-backed (stored server-side and loaded per user session), not reliant on client cache/storage. Losing bookmarks when switching browsers/devices or clearing cache undermines trust in the UI and discourages adoption of the feature. ### Acceptance criteria (suggested): - Bookmarks are stored server-side and associated to the authenticated user (or user profile settings). - Bookmarks persist across: - different browsers (Edge/Chrome/Firefox) - different machines - cleared browser cache/storage - Optional: include a migration path to import existing client-side bookmarks into the persisted profile on first load. ### Documentation improvement (at least until new feature implemented): - Update the Bookmarks doc to explicitly state current persistence behaviour and/or remove the caveat once bookmarks are account-persistent. - Update the Application Settings/Cache doc to clearly list that clearing cache removes bookmarks if bookmarks remain client-side, because right now it only gives an example (“theme”) and doesn’t explicitly mention bookmarks. ### PowerShell Commands (Optional) _No response_