Teams
Last updated: February 20, 2026
Deciding which teams to create in Rally to support the research access and tracking your organization needs.
About Teams in Rally
Teams help control access to studies, populations, sign up forms, templates, and budgets relevant to that team.
Core Principle: Access over Org Chart
Don’t assume you need as many teams in Rally as you have in your org chart. Create teams based on what they need access to. Ask yourself, "Who needs to see the same participants, templates, and budgets?"
Create a New Team: Create a team when a group of people needs a "siloed" or specific workspace to manage restricted data (e.g., sensitive customer segments) or specific financial resources.
Combine into One Team: If the product designers, PMs, and UXRs all work on the same product area and should share the same research templates and participant pool, they should likely be in one Rally Team together.
Common Team Models in Rally
Four common archetypes when considering what teams you will need::
1. Product or Business-Line Model (Most Common)
Structure: Create teams based on product pillars (e.g., "Growth Team," "Mobile App Team," "Checkout Experience").
Best For: Organizations where research is "embedded."
Why: This keeps the participant populations relevant. For example, the "Drivers" team in a delivery app shouldn't accidentally recruit from the "Merchants" population.
2. The Research Ops & Admin Team
Structure: A restricted team for ReOps leaders and Admins.
Best For: Managing global templates, workspace-wide governance, and total incentive budgets.
Why: It allows ReOps to build and "vet" templates or screeners before pushing them out to the broader organization.
3. The "Sandbox" or Training Team
Structure: A dedicated team named "Rally Learning" or "Sandbox."
Best For: New hires or stakeholders who are just learning the tool.
Why: Users can create "fake" studies, test sign-up forms, and experiment with features without cluttering real research data or accidentally emailing real customers.
4. The Centralized Research Agency Model
Structure: One large "UX Research" team that contains all researchers.
Best For: Smaller companies or centralized research teams that work as internal consultants across many products.
Why: It centralizes all studies and participants in one place for high visibility across the entire research department.
Key Decision Drivers
Use the following questions to guide how you’ll create teams:
Budget Control: Does this group have their own dedicated incentive budget that shouldn't be touched by others? (If yes, create a team.)
Participant or Study Privacy: Are there specific "Populations" (e.g., VIP customers or internal employees) or Studies (e.g. Secret Project) that only this group should be allowed to access? (If yes, create a team.)
Template Standardization: Does this group require their own specific consent forms or branding that differs from the rest of the company? (If yes, create a team.)
Pro-Tips
Membership is Fluid: A user can be on multiple teams. A PM might belong to their specific "Product Team" but also the "Sandbox Team."
Start Lean: Start with fewer teams. It is easier to split a team into two later than it is to merge disparate data from two teams into one.
Visibility for Admins: Admins can see all teams regardless of membership, so you don't need to join every team just to oversee work.