Your Team Library and Team Projects

A team is only useful if the material is in one place and the work survives the person who started it. Those are two different features — the team library and team-owned projects — and this page covers both.

Opening your team

Click Team in the sidebar. It opens on the Library, because the shared material is the reason the workspace exists. Five sections run along the top:

Billing is the only admin-only section. Everything else is open to every member, including the library.

The Team library

Team → Library lists everything anyone has shared with the team — sources and finished work together, newest first. A PDF someone uploaded sits beside the video lecture built from it, because in practice you want both.

Your own shares appear here too, labelled Shared by you. There is no separate "my shares" view to reconcile.

Filters by type. A row of filters — All, Sources, Documents, Podcasts, Meeting notes, Research, Chats, Folders & projects — narrows the list, and each one carries a live count, so you can see at a glance that the library holds nine sources and two research reports without clicking anything.

Search. The search box covers titles and the person who shared them. "Onboarding" finds the handbook; a teammate's name finds everything they contributed.

Every row names who and when. Each item shows Shared by name and when it landed, so provenance is never a mystery — you know whether you are looking at the policy the compliance lead posted or a draft someone tried out.

View counts. Items people have opened show a view count. It is the cheapest signal you have for whether the library is being used or just being filled.

If nothing is there yet, the empty state offers Share your first source or creation rather than leaving you to guess where sharing lives.

Shared work also appears in your own library

You do not have to visit the Team page to reach team material. Anything shared with the team shows up in your All Content alongside your own work, carrying a Team badge that names the person who shared it.

That is deliberate: a shared library that lives in a separate destination gets visited once. One that appears where you already look gets used.

Adding something to the library

There are two doors into the same room:

1. From the Team page — Team → Library → Add to library, then pick what to share.
2. From the item itself — open Share and choose Your team.

They are the same act. Either way:

• Every active member can open it.
• Ownership stays with the person who shared it. Editing remains theirs unless access is granted separately.
• They can make it private again at any time, and team access ends immediately.
• Removing a member ends their access to the library; everything they personally made stays in their own account.

This works for any content type — folders, pages, PDFs, recordings, podcasts, video lectures, meeting notes, research sessions, chats, and projects.

Team-owned projects

A project keeps the sources, creations, chats, and scheduled tasks for one piece of work together. A team-owned project answers the question sharing cannot: what happens when the person who built this leaves?

When a team owns a project:

• Every active member can open it without an invite. Nobody has to be added, and nobody has to remember to add them. New members get access by joining the team.
• Everything each member contributes stays in the project. Sources they add, creations they generate, files they file into its folders — all of it belongs to the project, not to their personal account.
• It survives the person who created it leaving. The project, its sources, and everything made from it stay with the team. This is the whole point.
• The project header names the owning team, so you always know which kind of project you are standing in.
• The Projects gallery groups team projects above your personal ones, under Team projects and Personal projects headings.

Transferring a project

Ownership moves in both directions, from the project's ownership controls. Each direction costs something specific, and the confirmation dialog spells it out before you commit.

Transfer to the team

The team becomes the owner. Every active member gets access to this project and everything in it, and the project stays with the team if you leave.

Use it for anything with a lifespan longer than your own involvement: onboarding, standing research, the client account someone else will inherit.

Transfer to a member

The member you choose becomes the personal owner. This one is lossy, and worth reading twice:

• The team and all existing invitees lose access.
• Public links become private.
• The new owner can set sharing up again from scratch.

Use it when work is genuinely leaving the team's orbit — a spin-out, a personal side project that ended up in the wrong place.

While a transfer runs, the project locks briefly and reopens a moment later under its new owner. Only one transfer can run at a time.

Private chats stay private

Team ownership does not change this, and it is the most important sentence on the page:

Project chats and project memories are never shared. Every member working in a team-owned project has their own private chats and their own private memories inside it. The shared sources, instructions, and content are common; the conversations are not. No other member, no project owner, and no team admin can read them.

The same is true of a project you share with individual people rather than the team.

Approving people who ask to join

Someone who lands on a private team item — a link a colleague forwarded, an old bookmark — can request access instead of hitting a dead end. Those requests collect on the People page under Requests to join, showing who is asking and what they asked for.

• Approve sends them a real team invite — the same invite as one typed into the invite box, filling a seat and giving them the library and the team's plan access.
• Deny dismisses the request.

If you are out of seats, approving is explained inline rather than failing: No seats available, with Manage seats taking you to Billing to add one. If a co-admin already handled the request, Scholarly tells you so instead of acting twice.

Setting the library up so people use it

A library nobody opens is the normal failure mode. Four habits prevent it.

Share the sources people actually reach for, not summaries. A shared PDF can be turned into a dozen different things by a dozen different people. A shared summary can only be read. The source is the reusable asset.

Organise by recurring job, not by person. One folder per job someone repeatedly does — Onboarding, Product, Policies, Customer calls — beats one folder per teammate. People come to the library with a task, not with a colleague in mind.

Replace superseded documents instead of adding a second copy. Grounded answers are only as good as what is in the library, and two versions of the same policy produce answers that split the difference. Swap the old one out.

Put something in it before you invite anyone. Invite emails name the most recently shared items, so the invitation itself says what the person is joining — "the 2026 handbook and the Q3 onboarding walkthrough" rather than a bare request to sign up. A new member landing in an empty workspace has nothing to do and usually does nothing.

Related

• Sharing with Your Team — the Share window, ownership, and what each visibility level means.
• Managing Your Team — seats, roles, invitations, and the join link.
• Projects — tabs, instructions, memory, and scheduled tasks inside a project.
• Data, Privacy, and Model Controls in Teams — what an admin can see, and the model policy controls.
• Rolling Scholarly Out to Your Team — a practical first-month plan for filling the library.