## Overview Organization is the top-level administrative layer that contains all groups, projects, and teams, providing a compliance boundary and complete data isolation. We are using organizations as a logical container for customer data to be able to move around from 1 Cell to another. This is a user impacting change. We need to release Organizations where all features work seamlessly, and we can ensure the current user experience and not disrupt future growth plans by customers. Zero disruption. No broken workflows. No missing features. Complete compatibility with .com before launch. This means complete feature parity is required before migrating any paying customers (FY27-Q3). We're building the foundation right, not rushing partial functionality to market. Using the [Operating Model](https://internal.gitlab.com/handbook/company/gitlab-operating-model/) we would like teams to: * Assess feature parity by completing the self-assessment survey. * Review findings with the Organization’s team. * Create issues under their respective epic as part of FY27-Q2 planning. ### Goals 1. **Organizations feature parity compliance:** Everything that works today continues working identically within organizations 2. **Organization level scoping:** Queries, permissions, and UI respect organization boundaries 3. **Zero disruption:** URLs, workflows, integrations, and user experience remain unchanged 4. **Speed to market:** Fastest path to launch with minimal changes, without introducing technical debt ### Non-Goals 1. **Introducing new features:** Not adding new features ahead of GA launch. Focus is on feature parity within an isolated organization context. 2. **Moving functionality between levels:** Settings stay where they are (group level SAML stays at group, project CI/CD stays at project). 3. **Changing existing functionality:** Features work exactly as now, just with organization context awareness. 4. **Addressing technical debt:** Existing fragmented functionality, code cleanup, or architectural improvements are out of scope. 5. **Redesigning user experiences:** Customer experience remains identical to today. **Why this approach:** Optimizing for speed to market. Organizations establish foundational infrastructure (data isolation, organizational structure) that customers need now. Future iterations introduce enhanced organization level features, move settings to logical levels, and address technical debt but only after delivering core value with zero customer disruption. ## DRIs * @mandrewsgl ## Exit Criteria - [ ] All groups finish their self-assessment - [ ] All features work organization context using a test organization on GitLab.com ## Step by Step Guide For Product Teams Overview: * Weeks 1-2 (self-assessment): Complete the self-assessment work item assigned to your Group in this epic. * FY27-Q2 (implementation & testing): Make features organization-compatible: update queries, permissions, UI, and APIs. Write automated tests. * Ongoing (track status) We will share a reporting issue to track weekly progress and updates starting in FY27-Q2. * When stuck: Post in [#proj_protocells_and_organisations_feature_parity](https://gitlab.enterprise.slack.com/archives/C0AD4AJGWK0) ### Step 1: Complete Self-Assessment (Weeks 1-2) **What:** Identify what needs to change for your group's features to work within organization boundaries.\ **Who:** Engineering managers or subject matter experts.\ **How:** 1. Under the [feature parity epic](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1871) find your group's self-assessment work item (e.g., The Geo team will find their self-assessment in [Tenant Scale \> Geo](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1954)). 2. Complete the [self-assessment questionnaire](https://gitlab.com/gitlab-org/architecture/readiness/-/blob/38550ffa1788b5cd84321274b0855e83b0f334efc667f1648831d7051bbe50ef/templates/platform_strategy/organization_support.md) for your group. 3. **When your self-assessment issue is ready, please set its Status to "In review".** This will add it to the [Organizations team's review board](https://gitlab.com/gitlab-com/gl-infra/tenant-scale/organizations/organizations-feature-parity/-/boards/11129188). The team will review and respond until the issue can be marked Done. 4. Any identified gaps need to be addressed in FY27-Q2. Create follow-up issues under your section/group epic. **Why**: Discovers whether features need query scoping, permission updates, UI changes, or architectural modifications before implementation begins.\ **Deliverable**: Completed self-assessment with follow-up issues created for implementation work. ### Step 2: Implementation & Testing (FY27-Q2) **What:** Execute the technical work to make features organization-compatible while maintaining complete feature parity.\ **Who:** Each individual group for their respective features.\ **How:** 1. **Database Query Scoping:** Apply organization level scoping to all database queries using sharding keys (organization_id, namespace_id, project_id). This prevents data leakage across organization boundaries. Some key concepts: 1. Sharding keys establish data ownership and enable isolation 2. Query scoping ensures features only access data within organization boundaries 2. **Permission & Authorization Updates:** Update permission models to enforce organization boundaries. Permissions cascade: Organization Owner, then Group Owner, then Project Maintainer. All authorization checks must verify user access within the current organization. 3. **UI Component Updates:** Modify user interfaces to display organization scoped data only. Update views to show organization context and ensure all displayed data respects organization boundaries. 4. **API Endpoint Updates:** Update REST and GraphQL APIs to scope responses to the current organization. Use set_current_organization helper in Grape API endpoints. GraphQL queries automatically receive Current.organization context. 5. **Background Job Handling:** Explicitly pass organization context or derive from related data (e.g., issue to project to organization). 6. **Continuous Testing**: 1. Write automated tests covering organization context for every feature 2. Validate features work identically within organizations as they do today 3. Test organization isolation boundaries to prevent data leakage 4. Validate performance meets or exceeds current implementation 5. Test migration scenarios to ensure zero data loss 7. **Progress Tracking** (ready by FY27-Q2): Monitor progress through the **Technical Readiness & Testing Dashboard** (coming soon): showing test coverage, compatibility status, and real-time progress toward 100% completion. **Deliverable:** Fully implemented and tested organization-compatible features with automated test coverage demonstrating zero functionality gaps. ### Step 3: Product Manager Sign-Off (Ongoing Q2-Q3) **What:** Validate functionality works correctly within organization boundaries before marking complete.\ **Who:** Group Product Manager or Product Manager\ **How:** 1. Manually test features in organization context using a test organization on GitLab.com 2. Verify all acceptance criteria from feature issues are met 3. Confirm no performance degradation compared to current implementation 4. Validate UI/UX matches current experience with organization scoping 5. Test edge cases and cross-feature workflows 6. Sign off on stage epic only when all features are validated. Example: the Tenant Scale group product manager will close off the [Tenant Scale stage epic.](https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1950) Acceptance criteria applied to ALL features: * Feature works identically within organization context * All existing functionality preserved (zero disruption) * Organization level scoping applied appropriately * Migration maintains all settings and data * Performance matches or exceeds current implementation * Feature tested across organization isolation boundaries **Why:** Product Manager validation ensures features meet customer expectations and maintain the zero-disruption commitment. Human validation catches usability issues or workflow disruptions that automated tests might miss.\ **Deliverable**: Product Manager approval comment on group epic confirming all features meet acceptance criteria and are ready for customer use. ### Step 4: Weekly Progress Updates (Throughout Q2-Q3) **What:** DRIs (Directly Responsible Individuals) for each group provide weekly status updates.\ How: Post in [#proj_protocells_and_organisations_feature_parity](https://gitlab.enterprise.slack.com/archives/C0AD4AJGWK0) using this format: * Completed this week: Features that achieved organization parity * In progress: Features currently being implemented/tested * Blockers: Dependencies, technical challenges, or unclear requirements * Next week goals: Features targeted for completion * Risks: Potential timeline impacts or scope concerns Why: Weekly updates create visibility, enable early intervention on blockers, and keep the massive coordination effort aligned. With 792 features across dozens of teams, frequent communication prevents bottlenecks.\ Deliverable: Weekly status update from each group DRI tracking progress toward 100% feature parity. ## Success Metrics The program succeeds when all 792 features achieve organization parity: * Zero customer reported functionality gaps: Every feature works identically in organizations as in groups * Zero performance degradation: All features meet or exceed current performance benchmarks * 100% automated tests passing: Comprehensive test coverage validates organization compatibility * Complete documentation: All features documented with organization examples * Zero data loss in migration: Customers can migrate with full confidence * Correct isolation boundary behavior: No data leakage across organization boundaries Delivery Timeline: FY27-Q3 ## Critical Principles 1. **Complete Parity Required:** There is no MVP and no phased feature rollout. Every feature must work as expected within organizations before launch. This is the foundation of the zero-disruption commitment to customers. If a feature doesn’t work it’s up to each product team to address this breaking change. 2. **No Prioritization:** All features are equally important. We cannot launch with partial functionality. The `create` stage without `verify` is not sellable to our customers. 3. **Systematic Validation:** Self-assessment, implementation, automated testing, and PM validation create multiple validation gates ensuring quality. The Technical Readiness Dashboard provides real-time visibility into progress and gaps. 4. **Collaborative Execution:** Weekly updates ensure teams stay aligned, blockers get resolved quickly, and expertise flows freely across the organization. This is a company-wide effort requiring unprecedented coordination. ## Resources 1. [Organization development guidelines](https://docs.gitlab.com/development/organization/) 2. [Database sharding guidelines](https://docs.gitlab.com/development/organization/sharding/) 3. Slack channel [#proj_protocells_and_organisations_feature_parity](https://gitlab.enterprise.slack.com/archives/C0AD4AJGWK0) 4. [Organization design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/)