feat(admin): allow hiding user-defined collections from admin sidebar

[khoinguyenpham04]

This Roadmap discussion mirrors #1131: feat(admin): allow hiding user-defined collections from admin sidebar.

Use this discussion to upvote the roadmap item and discuss priority, use cases, and product feedback. Keep implementation tracking, reproduction details, and PR-specific feedback on the source issue.

• Source issue: #1131
• Status: Open
• Labels: roadmap/1.0, roadmap/editor-experience
• Original author: austinkern

Original Issue

Summary

Allow user-defined collections to be hidden from the admin sidebar via a flag on the collection definition. Complements #863 (which addressed built-in features).

Motivation

When a plugin manages a collection end-to-end (autocreating entries, providing its own admin UI), the raw collection list view becomes redundant clutter. Editors should be guided to the plugin's UI, not the auto-generated CRUD page.

Concrete example: A lead-notes-autofill plugin owns two collections — contact_submissions (autopopulated by the contact API) and lead_notes (1:1 with submissions, also autocreated). The plugin ships a "Lead Inbox" admin page (/_emdash/admin/plugins/lead-notes-autofill/inbox) with search, sort, assignee, and inline editing. The raw Content > Contact Submissions and Content > Lead Notes sidebar entries are never used in practice but show up next to legitimate editable collections like Blog Posts and Employees, confusing editors.

Per the current docs, "Navigation is generated from your collections and installed plugins" — but there's no opt-out per collection.

Proposed API

A hidden: true flag on the collection definition (mirroring the supports array):

{
  slug: "contact_submissions",
  label: "Contact Submissions",
  icon: "mail",
  supports: ["search"],
  hidden: true,  // ← new: collection still exists, sidebar entry omitted
  fields: [ /* ... */ ]
}

Setting hidden: true should:

• Omit the sidebar entry under /content/ in the admin
• Keep the collection fully functional via the REST API, MCP tools, plugin hooks, and direct /content/:collection URLs (so plugins can still manage the data and admins can navigate directly if needed)
• Not affect schema, migrations, or query behavior

Alternatives Considered

• CSS injection — fragile, breaks on UI updates.
• Repurpose label to discourage clicks ("Lead Notes (managed by Inbox)") — hacky and the entry still consumes a slot.
• Roles — too coarse; would affect more than these collections.

Context

Real-world install: an Astro site with a custom lead-notes-autofill plugin that fully owns its two collections. Pairs well with the recent adminPages support in plugin descriptors.