Rally Foundations Strategy Guide
Last updated: April 27, 2026
What This Resource Is (and Isn’t)
This guide helps you plan and configure the foundations of your Rally workspace before your team starts running studies. It covers the structural decisions, like how to organize your participants, who gets access to what, and how to protect people from over-contact, that are difficult and expensive to change later.
This is a strategic decision-making guide, not a how-to manual. Each module walks you through the key considerations and trade-offs so you can make informed choices that fit your organization's research practices, policies, and scale. For step-by-step feature instructions, refer to the Rally Help Center, which is also referenced throughout each module.
Before diving into foundations, ensure your workspace and technical integrations are underway. Your Rally Implementation Consultant or Customer Success Manager will guide you through technical setup including SSO, custom email domains, calendar and conferencing tools, and any data integrations. These often involve IT teams and review queues, so starting them early is important.
How to Use This Guide
Most customers work through these modules over 4-6 weeks, involving stakeholders from research, IT, legal, and data teams at different stages. Each module includes guiding questions designed to surface the decisions you'll need alignment on to best configure Rally.
You don't need to have perfect answers on day one. But working through these decisions in the suggested order prevents rework when later decisions depend on earlier ones.
Decision Sequence: What to Tackle and When
The foundation of your Rally workspace is built in five steps. Each one builds on the last, so the order matters.
1⃣ Properties & Schema
Define the participant data fields (properties) your workspace will use, how participants are uniquely identified, and which data is self-reported vs. synced from external systems.
Why first: Properties are the building blocks for everything else. You can't segment populations, write governance rules, or build useful screeners without a clear property schema.
🔖 Modules: People Database, Properties
2⃣ Populations
Decide how to organize your participants into distinct groups based on their relationship to your organization and products. Populations determine who researchers can reach and how participants experience your outreach.
Why second: Population structure depends on the properties you defined in Step 1. Get this wrong, and your governance rules and team access won't work as intended.
🔖 Modules: Populations
3⃣ Teams & Permissions
Define which researcher roles exist, what each role can do, and which teams have access to which populations and workspace features.
Why third: Role and team structure should reflect the populations and data access boundaries you've already established.
🔖 Modules: Teams, Roles & Permissions
4⃣ Governance Rules
Set global and population-specific rules for contact frequency, participation limits, cooldown periods, and incentive caps. These rules protect your participants and your brand.
Why fourth: Governance rules reference populations, properties, and team boundaries — all of which need to exist first.
5⃣ Templates, Consent & Branding
Configure study templates, screener question libraries, email templates, consent forms, branding assets, and incentive budgets. This is the operational layer that sits on top of your structural foundation — the bridge between "workspace is configured" and "researchers can launch studies."
Why last: Templates and consent forms should reflect the governance rules, branding decisions, and population structure you've already locked in. Building these first could lead to rework.
🔖 Modules: Templates, Consent, Brands, Email Domains & Footers, Budgets & Incentives