Skip to main content
Collections give you a way to manage content that doesn’t belong in your main Library, without losing structure or visibility. They’re ideal for keeping content organized by purpose, audience, or lifecycle — and for making sure the right content shows up in the right context. This page helps you build a mental model for when and why to use Collections as part of your content strategy.

​
A separate library with a specific purpose

Every Collection is a standalone library. The content it holds is fully separate from the Library and from other Collections — even if it’s based on the same original family file. This makes Collections perfect for managing specialized, or audience-specific contentt. For example:
  • You might keep a client’s custom title blocks in one Collection.
  • You might evaluate a manufacturer’s dataset in another.
  • You might gather early-stage proposals in a Collection used by content contributors.
Collections give you control and clarity without cluttering your main content pool.

​
When Collections are a good fit

You don’t need a Collection for everything. But there are clear situations where they shine:
  • Project packs: Bundle the specific content a project needs — not just families, but also sheets, views, and templates — and assign it directly to the project.
  • Client standards: Isolate title blocks, tags, or naming conventions that apply to one client but not to others.
  • Manufacturer content: Keep vendor-provided families separate so they’re accessible but not promoted in search results.
  • Legacy or historical sets: Maintain access to older content without keeping it in your Library.
  • Work-in-progress: Give contributors a place to stage ideas, refinements, or reviews before they’re approved.
  • Confidential work: Use restricted Collections (paired with restricted projects) to control access to sensitive or private content.
Collections also play an important role in search experience and prioritization.
  • By default, Collection content appears below Library content in Revit and web search.
  • When you assign a Collection to a project, its items are promoted to the top of the results — and shown as Project content, marked with a blue icon.
  • This makes sure that content intended for that project is always quick to find and clearly marked, without changing global priorities for other users or projects.

​
Controlling visibility and contributions

Collections are flexible by design. You control who can see them and who can contribute to them.
  • A Team Collection is visible to all members.
  • A Restricted Collection is only visible to admins or security admins, and users you’ve explicitly granted access.
By default, only Content Managers and Admins can add or modify content — but you can change that. You can enable all users to add and modify content in a Collection, or share it with individual users with the permission to edit.
If you open a Collection up for contributions from all members, it’s often helpful to hide its content from Revit search. This lets people suggest and upload freely, without the unapproved content polluting searches.

​
Collaborating with others

Collections also support external sharing and cross-team collaboration:
  • Share with individuals or groups inside your organization, with view or edit permissions.
  • Collaborate with another Kinship team, such as a partner firm or consultant, with shared edit access.
  • Share a read-only web link to let non-Kinship users browse and download content without a login.
Each of these modes is useful for different workflows — whether you’re gathering feedback, aligning with partners, or distributing content to external reviewers.

​
Good patterns to follow

Over time, some patterns tend to work well for teams using Collections intentionally:
  • Keep each Collection focused. Make it obvious what it’s for and who it’s for.
  • Pair project assignment with a real-world need. A Collection assigned to a project is most effective when it supports something concrete — like a client specific standard.

​
Pitfalls to watch out for

A few common anti-patterns can make Collections harder to manage:
  • Overlapping the same content across Collections. Items in Collections are independent. If the same family is placed in two Collections, each becomes its own copy — updates made in one won’t affect the other. This makes maintenance harder and risks inconsistencies. If the content is truly the same, it’s likely better suited to the Library, where it can live in one place and be included in multiple Lists as needed.
  • Mixing too many audiences in one Collection. Keep client-specific, project-specific, or internal-only content separate. This makes it easier to avoid overlap.
  • Expecting shared Lists or behavior from the Library. Collections are self-contained. They don’t support Lists or the Pending Approval section.
  • Leaving early-stage work visible in search. If content isn’t ready, hide the Collection from Revit search until it is.

​
Real-world examples

“We need a client-specific kit for a framework agreement.”
Create a Collection with their content, assign it to those projects, and users will see it first in Revit search — clearly marked and easy to load. “We’re modifying manufacturer-provided content to align it with our standards.”
Drop it into a Collection, keep contributions limited, and hide it from search. Review and promote the content that passes your standards. “We have legacy content that’s still useful on occasion.”
Place it in a Collection with no project assignment. It stays searchable but doesn’t take up space at the top of results.

​
Learn more