## Problem Organization admins on GitLab.com cannot reliably control settings across their hierarchy. Settings inheritance is unpredictable, enforcement options are inflexible, and there's no clear visibility into which entities have which settings. Confusing terminology around policies vs. preferences compounds the issue. This forces admins into manual workarounds while struggling to maintain security, compliance, and consistency. <details> <summary> #### Goals & Requirements </summary> ### Goals **Improve administrator confidence and efficiency** when configuring settings across all organizational levels by providing: 1. **Centralized Control** * Organization-level settings automatically apply to all existing subgroups and projects (not just new ones) * Clear visibility into all settings across the entire hierarchy * Easy identification of inherited vs. overridden settings 2. **Flexible Enforcement** * Support for strict enforcement (locked settings) * Support for recommendation-based approaches (groups can override defaults) 3. **Clear Policy vs Setting Distinction** * Defined criteria for when something is a policy (mandatory) vs. a setting (customizable) 4. **Consistent Language** * Uniform terminology throughout the interface (e.g., consistent "allow" vs "restrict" wording) ## ### Core requirements **Priority 0 (Must Have):** * Centralized settings management interface * Multi-level inheritance: Organization → Group → Subgroup → Project * Selective enforcement with three modes: Enforced | Recommended | Default * Unified experience across self-managed, GitLab.com, and dedicated instances * Pathway to move admin area functionality into organization settings **Priority 1 (Should Have):** * Compliance support: Integration with compliance frameworks for regulatory requirements * Policy framework implementation **Priority 2 (Nice to Have):** * Support for grouping projects by business criteria (risk level, compliance requirements, security posture) rather than being limited to organizational structure alone </details> ## Design proposals **(1) Settings inheritance overview** {width="900" height="563"} User values: * Searchable table of all settings at a selected level * Filter by setting name or category * Shows **enforcement status**, **source** (inherited/local), and **current values** * Quick action buttons to configure **Control mode** {width="900" height="563"} User values: * Organizations can mandate critical settings across all groups and projects * Prevent misconfigurations and guide teams at lower hierarchy levels * Gradually adopt best practices through recommendations before making them mandatory **(2) Admin audit view** {width="900" height="563"} User values: * Compliance dashboard with **metrics** (Compliant, Overrides, Violations) * **Searchable audit table** across groups and projects * Color-coded status (green/yellow/red) * Action buttons to enforce, review, or edit specific settings * Shows which resources violate enforced policies ### Design assets * Latest design file: [Figma design](https://www.figma.com/design/xW2ETjb9hA7pgtVnMdxGJB/Organization-Settings?node-id=0-1&t=QxZt5VVLQ24fIanp-1) * Lo-fi wireframe and discussion: [FigJam](https://www.figma.com/board/gITrIbrenbKkG4OGtrXNmQ/Organization-settings-enforcement?node-id=0-1&t=FOEIEvfNZyCujSXc-1) * AI prototype: [Claude](https://claude.ai/artifacts/448da13a-c90f-409d-9b8f-60b14b45d203) ### Backlog ideas * **Configuration centric view -** Admins can review a specific setting across all groups and projects, and make bulk updates in one place.