/ /
DevRev's mission is unlocking team potential through human-AI collaboration, what we call Team Intelligence. Teams delivers on that structurally: it gives every group a workspace shaped around how they work, with scoped knowledge and specialized AI that compounds Memory and intelligence at the team level rather than scattering it across the workspace.
A team is a working group with shared configuration, shared Memory, and a shared AI teammate. Teams provide:
A shared workspace
Each team gets a dedicated workspace with team-specific settings, configuration, and views.
Autonomy
Teams control their own configurations, object subtypes, custom objects, and custom fields.
Personalization
Team admins shape the workspace for their members: default views, templates, and preferences that make the team's experience feel purpose-built.
Context
Teams power intelligent defaults and suggestions. Team membership determines which shared agents you can talk to, and AI agents can scope knowledge to your team. Attributes like owner, part, and sprint auto-fill based on team context.
Ownership
For work records like issues, enhancements, and tickets, Teams represent ownership, making it clear where work sits in the team hierarchy and who is responsible.
Key concepts
Team hierarchy
Teams support hierarchical relationships that mirror your organizational structure. A parent team (such as "Engineering") can contain child teams (such as "Identity", "AirSync", "Customization"), which can have their own sub-teams.
Hierarchy enables:
Member roll-ups: Members of child teams are visible at the parent level.
Configuration inheritance: Customizations defined at the parent level (subtypes, stages, fields) are automatically available to all child teams.
Data roll-ups: Issues from child teams automatically surface on the parent team when the Include child teams toggle is enabled.
Aggregated metrics: Leaders can view analytics across the full hierarchy without manual assembly.
Team workspaces
Each team comes with a dedicated workspace that provides:
Scoped permissions and access control.
Team-specific navigation and default views.
Configuration isolation (subtypes, custom fields, custom objects & more).
A boundary for AI agent context and recommendations.
Workspaces keep each team's configuration separate while maintaining full cross-team discoverability, focus without losing connectivity.
Teams vs. Groups
Teams and Groups (Access Groups) serve different purposes:
Aspect | Teams | Groups (Access Groups) |
|---|---|---|
Purpose | Work management, navigation, and team identity | Access control and permissions |
Hierarchy | Parent-child relationships with configuration inheritance and data roll-ups | Flat; no inheritance or roll-ups |
Customization | Autonomy over object schemas, subtypes, and more | No configuration ownership |
Scope | Shapes default views, search, and AI context | Controls what users can see and do |
How Teams is used across DevRev
Teams is a platform-level primitive that surfaces differently depending on your use case.
Work scoping and navigation
For engineering, product, and design teams using Computer+ Build, Teams unlocks team-first navigation with dedicated views, custom work-item prefixes (AUTH-23, PAYMENTS-107), smart field suggestions, and team-scoped schemas. Every EPD team gets a ready-made workspace for issues, sprints, roadmap, and team health.
Agent sharing and access
Teams is the access primitive for shared agents. Admins create agents in Agent Studio, a Sales Agent, Support Agent, Engineering Agent, and share them with teams. Everyone on that team can talk to the agent, with data access always scoped to the individual user's permissions. Support teams can similarly use Teams to scope tickets, conversations, and agent routing to specific groups, enabling multi-brand or multi-team support operations within a single workspace.
Set up Teams
Create a team
Only org admins can create teams.
To create a team, go to Settings > Teams and complete the following steps:
Enter a name and description for the team (for example, "Platform Engineering").
(Optional) Set the parent team if this team belongs within a hierarchy (for example, parent = "Engineering").
Add members by inviting individual users or adding groups.
Assign team admins to manage membership, configure settings, and customize the team's schema.
Once created, the team appears in Settings for all its members. On Build plans, it also appears as a named entry in the left navigation, where members can access the team's workspace, views, and configuration directly.
Default team
New workspaces start with a default team pre-created. Every user who joins the workspace is automatically added to this team, providing an immediate starting point.
Team membership
Members can belong to multiple teams simultaneously.
Adding a user to a child team automatically makes them visible at the parent level.
Team admins manage membership from the team's settings panel (Team > Settings > Members).
Both individual users and groups can be added as team members.
When inviting new users to the workspace, you can specify which teams they join.
Team identifiers
Each team has a short identifier (3–5 characters, for example, AUTH or INFRA) that serves as a prefix for work items created within the team. Identifiers can be changed after creation.
Structure your teams
Teams should mirror how your organization works together and ships, not your HR reporting hierarchy. Reporting lines can cross team boundaries.
Common patterns
Pattern | Examples | When to use |
|---|---|---|
Cross-functional teams (recommended) | Checkout (eng + design + PM), "SOC2 Compliance" initiative, EPD | Groups organized around a shared mission across disciplines |
Sub-teams within a function | Auth, Payments, Platform (under Engineering); L1, L2 (under Support) | When a function has distinct sub-groups that need their own workspace |
Isolated departments | People Ops, Finance, Legal, IT | Functions with distinct workflows that don't overlap with other teams |
Use hierarchy to model these: parent team = function or org group, child teams = the sub-groups within it.
What Teams is not for
HR org chart mapping: Don't create a team for every reporting line, create teams for groups that actually collaborate.
Individual people: That's what user profiles are for.
Access control: That's what Groups (Access Groups) are for.
Get started
Start with one or two teams that represent your most natural working groups. Validate that the structure feels right before expanding. You can reorganize the hierarchy at any time without disrupting existing work.
Availability
Teams is available on select DevRev plans. The specific features available to your organization depend on your plan tier. To confirm what is included on your plan or to enable Teams for your workspace, contact your Customer Success Manager or DevRev Support.
Cross-team collaboration
Teams are designed for collaboration, not isolation:
Cross-team mentions: @mentioning someone from another team automatically surfaces the context they need.
Shared data: Data in teams can remain globally accessible or limit access to the team, based on access policies set by the team admins.
Shared views: Create views and dashboards that aggregate data across multiple teams.
Adopt Teams
Teams is additive, enabling it does not disrupt your existing setup. Nothing changes until you actively create teams and start using them. Existing work items, views, integrations, and workflows continue to function exactly as before.
For detailed guidance on each use case, see:
Custom Agents - Talk to Your Team's Agents: Setting up shared agents, the agent picker, and multiplayer agent chats.
Teams for Build: Migrating existing work, adopting team prefixes, updating integrations, and configuring team-scoped schemas.
FAQs
Q. Can someone be on multiple teams?
Yes. Users can be members of multiple teams simultaneously. When creating work, they select which team it belongs to.
Q. What happens to work items if I move a team?
Moving a team to a new parent updates roll-ups and the team hierarchy but does not affect the work items, views, or workspaces belonging to that team. Existing assignments and history are preserved.
Q. What if we need to reorganize the hierarchy later?
You can change parent/child relationships at any time in Settings > Teams. Moving a team to a new parent updates roll-ups but doesn't affect existing work items or team workspaces.
Q. Does enabling Teams break anything?
No. Teams is additive. Nothing changes until you actively create teams and start using them.
Learn more
Computer+ Build course on DevRevU: Team-first workflows and navigation patterns.
User management and groups: Understanding teams, groups, and permissions.
Was this article helpful?