Candidate
A proposed link with a reason and intended collection.
Team bookmarks
Use collection charters, candidate and approved states, clear owners, access rules, canonical links, and risk-based review dates.

Collection charter
A one-paragraph charter prevents vague collections from absorbing every link the team encounters.
Support runbooks contains the canonical troubleshooting and escalation links used by support leads. Anyone on Support may propose a link; the Operations owner approves or archives. High-risk links are reviewed monthly. Credentials and case-specific tickets do not belong.
Make the charter visible at the point of contribution, not hidden in a separate policy document.
Lifecycle
Users should be able to see whether a link is a lead, reviewed resource, canonical destination, or historical record.
A proposed link with a reason and intended collection.
Relevance, access, source, title, and duplication have been checked.
The preferred link for a recurring task, answer, policy, or tool.
Retained for history but removed from active views and onboarding paths.
Safety and access
Titles, collection names, query strings, and shared context can expose confidential projects even when the page requires login.
Place links only in spaces whose access matches the underlying work. Create a curated external collection for partners.
Never store passwords, tokens, or temporary access keys in bookmark titles, notes, or URLs.
Use maintained landing pages when possible; label dated files, filtered views, and mirrors clearly.
Useful first collections
A small trusted collection proves the workflow before organization-wide migration.
Required links grouped by first-day and first-project outcomes.
Approved case studies, public examples, and reusable evidence.
Runbooks, policies, status pages, and escalation destinations.
Dated observations connected to canonical pricing, docs, and product pages.