Create and manage teams

A team is a named group of people in your organization. Teams are available on every plan, and they exist so that other features can address a group instead of a list of individuals: capacity and workload views, timesheet expectations, intake notifications, and agent access all understand teams.

A person can belong to as many teams as makes sense. Teams do not nest.

Create a team

1. Open People in the sidebar, then the Teams tab.
2. Select New team and give it a name your organization already uses out loud, such as Design, Platform, or PMO.
3. Save. The new team appears in the list on the left, with its detail and workload pane on the right.

Create teams that match how work is actually assigned. Org-chart layers that nobody plans work by add maintenance without changing any of the views below.

Add and remove members

1. Select the team in the Teams tab.
2. In the detail pane, add people from your organization’s members.
3. To remove someone, use the remove control on their row. They stay in the organization and on their projects; only the team membership ends.

Membership is ongoing rather than a setup step. Add people as they join and remove them as they move on, because the capacity, timesheet, and notification behaviour below all read the team’s membership at the moment they run rather than a snapshot from when the team was made.

Deactivated people cannot be added

If someone has been deactivated in your organization, adding them to a team is refused and the attempt is recorded in the audit log. Reactivate them first. This applies to agents acting on your behalf as well as to people using the app.

Teams are not a permission

This is the most common wrong assumption about teams, so it is worth stating plainly: you cannot assign a permission to a team.

Onplana resolves every permission against a person’s role, either their organization role or their role on a specific project. There is no team axis in the permission matrix, and adding someone to a team grants them nothing. To change what a group of people can do, change their role, or define a custom role and assign it.

The one place a team appears in an access decision is narrower than a permission and worth keeping distinct:

• A library, list, or page that has been switched to restricted access can be shared with a team from that item’s Share dialog. Doing so lets that team’s current members open that one item, at the level you choose (view, contribute, or manage).
• That is a grant on a single resource, not a permission. It does not change anything the person can do anywhere else, and it disappears when the resource does.

See understand roles and permissions for how permissions actually resolve.

What teams actually drive

Feature	What the team does
Capacity and workload	The workload pane shows a team’s combined load, and capacity views can be read per team
Timesheet expectations	Expected weekly hours can be set per team, so a team’s norm differs from the organization default
Intake forms	A form can notify a team, resolved to its members at the moment a submission arrives
Project invitations	A whole team can be invited to a project rather than adding people one at a time
Restricted workspace items	A team can be granted access to a specific restricted library, list, or page
Agent access	An AI agent’s reach can be allowed or denied by team

Belonging to more than one team

When a person is in several teams that each set different expected weekly hours, Onplana resolves the conflict with the most generous setting by default. An owner or admin can change that to first team or most restrictive in the timesheet enforcement settings. See set expected hours overrides.

FAQs

Who can create and edit teams? Owners, Admins, and Portfolio Managers by default. The underlying setting is the org.team.manage permission, so an owner can widen or narrow that in the permissions matrix. Everyone else in the organization can see teams but not change them. Guests cannot see the Teams tab at all.

Does adding someone to a team give them access to that team’s projects? No. Team membership and project membership are separate. Inviting a team to a project is an action you take on the project, and it adds those people as project members at that moment.

Can a team contain people from another organization? No. Teams contain members of the one organization. External people join as guests first, and a guest can then be added to a team like anyone else.

Do teams nest? No. There is no parent or child team. Model a hierarchy with several flat teams and put people in more than one where it applies.

Does a team cost anything? No. Teams are on every plan and have no seat cost of their own. Only people are billed, and only once, however many teams they are in. See manage seats and guests.

Best practices

• Name teams the way people say them out loud. The name appears in pickers across capacity, intake, and sharing, so a name nobody recognises makes every one of those harder.
• Keep teams to how work is assigned, not to reporting lines. If no view would ever be filtered by a team, it does not need to exist.
• Prune membership when people move. Stale membership quietly skews capacity and can keep sending intake notifications to someone who has moved on.
• Reach for a role, not a team, when someone needs more ability. If you find yourself wanting to add someone to a team so that they can do something, the answer is their role.

Troubleshooting / common pitfalls

• The New team button is missing. You are below the tier that org.team.manage allows, which is Portfolio Manager by default. An owner can adjust it in the permissions matrix.
• Adding a person is refused. They are most likely deactivated in the organization. Reactivate them and try again; the refusal is in the audit log.
• Someone was added to a team but still cannot open a project. Expected. Teams grant nothing on their own. Add them to the project, or invite the team to it.
• A team was given access to a document and members still cannot see it. Check that the item is actually set to restricted access. On an unrestricted item, access follows role, and the grant list does not apply.
• Expected hours look wrong for someone in two teams. The most-generous rule is resolving the conflict. Change the conflict setting, or take the person out of one team.

How this combines with other features

Teams are a grouping primitive, so they are most useful once something consumes them. The usual order is to create teams during setup, then set capacity so workload views mean something, then set per-team timesheet expectations if your organization tracks time.

Agent access is the one place where a team is a boundary rather than a convenience: restricting an agent to named teams is how you keep it out of work it should not see.

Related

• Understand roles and permissions, how access is actually decided
• Create custom roles, the right tool when a group needs different abilities
• Invite your team, getting people into the organization first
• Plan team capacity, the main view teams feed
• Set expected hours overrides, per-team timesheet expectations