Teams
A team is a named group inside your account - an office, a discipline, a client, a market - that people belong to and work can be shared with. Every team gets a page named after the team itself - "Water" - holding the material that team has adopted.
If a team is the scope things get shared with, its page is the place they end up. See How access works.
A team page with its five sections
Getting there
From your account menu. If you belong to more than one team, the menu shows your first alphabetically; the others are a click away from there. If you belong to no teams, there's no team entry - there'd be nothing on it.
What's on it
Five sections:
| Section | What's in it |
|---|---|
| Checklists | The team's shared checklists |
| Revit Workflows | Saved routines for the Revit add-in |
| Workflows | Workflows the team has adopted |
| Resources | A general file store for the team |
| Codes | The team's code books, as a plain list |
Everything here is on the page because someone tagged it to the team and a lead approved it. That's the point: a team page is a curated shelf, not a dump of everything anyone in the team has ever made. See How access works.
Resources
Resources is the section with no equivalent anywhere else: a place for the team's own files - the CAD standard, the client's title-block template, the reference document everyone on that market needs at hand.
Anyone in the team can upload. What happens next depends on who you are:
- A lead's upload goes straight onto the page, approved.
- A member's upload lands as a pending request and shows an Awaiting review chip until a lead accepts it. It doesn't quietly join the shelf, and it doesn't vanish either.
The reviewer is the team's lead, or an org owner where the team has no lead yet - so the confirmation never names an approver who doesn't exist.
For team leads
The team page is also your workbench. Three things live in the manage view:
Your team's queue. Pending requests to share something with this team, each opening an evidence panel with the item, the same accept / decline controls whatever kind it is, and the conversation thread underneath. A decline needs a note; see How access works.
Organization requests. A separate, org-wide queue. Because the org-door review pool is org owners plus any team lead, leading one team puts these in front of you too. The same queue appears on the Dashboard.
Members. Add any active person in your organization to the team, and remove plain members. You can't remove another lead - granting and revoking the lead role stays with the org owner, on the Dashboard.
Two limits worth knowing: your own shares into your team still go through the queue (that's deliberate - it's what teaches leads the queue exists), and you can't browse members' private drafts, only what has actually been offered to you.
Sub-teams
A team can hold sub-teams beneath it - a discipline inside an office, a client account inside a market - as deep as your organization needs. A sub-team behaves like a team: it has its own page, its own members and its own queue, and its name reads as the path to it ("Federal / Structural").
Sharing runs downhill. Something shared with a team is visible to that team's members and to everyone in the teams beneath it; something shared with a sub-team reaches that sub-team alone. Org owners set up the structure on the Dashboard; a team lead can build out the sub-teams below a team they lead.
Asking to join a team
If your work has moved and you should be in a team you're not in, you can request to join it. It goes to the same reviewers as a share request.
An org owner adding you to the team directly settles any pending request you had - you won't end up with a stale request hanging around after you've already been added.
Where else teams show up
The team page isn't the only place teams matter. Once your organization uses them, they narrow things across the platform:
- The code library - a published book can be tagged to specific teams, so the Texas amendments file under the Texas team's shelf instead of cluttering the Ontario library. Tags on a published book organize; they don't restrict who can read it.
- Workflows - shared workflows group by team.
- The Dashboard - stats break down by team, so an owner can compare offices or disciplines. A project belonging to two teams is counted in both.
- Projects - a project carries its teams, which is what makes that breakdown work.
Teams gate, disciplines label
Two things on the platform look like filters, and only one of them is.
Teams are an access boundary. Something shared with a team is visible to that team's members and to org owners - nobody else. Other people don't see a locked version of it; it simply doesn't appear in their lists, and a team page you're not a member of won't open at all.
Disciplines are a label. Your discipline is self-selected, it preselects a chip here and there, and you can always clear it to see every discipline's material. A discipline chip narrows what you're looking at; it never hides anything from you.
Either way, what you see is trustworthy: anything a team page or list shows you, you're allowed to see. Confidential material is kept out of your lists by the platform itself, never by a filter you could clear.
A retired team
If a team is removed from your organization's list, its page still opens and says so. You can't share anything new into it, but what's already there stays visible and its grants stay revocable. See How access works.
Teams are switched on per organization. With no teams configured, the team entry and the team controls simply don't appear. If you want them, talk to us.