Overview

Open edX configurations are scattered across multiple tools and levels (Instance, Site, Organization, Course). Many are hidden in developer-facing areas like Django Admin or Tutor files, while others live in Studio, LMS, or the Instructor Dashboard. This fragmentation makes configuration hard to manage and limits access for non-technical roles.

A new Administrator Console is being planned. To design it effectively, we first need a clear map of current configurations: where they live and what parts of the platform they affect.

Context

1 - Platform Levels

Open edX is a complex platform with multiple hierarchical levels. Changes applied at higher levels cascade down and affect the levels below. The hierarchy is:

• Instance → the entire deployment.
• Site → specific branded portals within an instance.
• Organization → groups of courses, often mapped to schools or institutions.
• Course → the teaching units.

Not all concepts are hierarchical. Some apply to a single level only (e.g., enrollment), while others require different configurations at each level. In addition, not all deployments enable every level (e.g., a single-tenant instance may only include one site).

2 - Product Experiences

Currently, the platform revolves around several course-level product experiences:

• Studio → for course authors to build and manage courses.
• LMS → for learners to access and take courses.
• Instructor Dashboard → for course operators to manage students in active courses.
• Aspects → a course-data experience that may evolve to support cross-course needs.
• Django Admin → where most non-course configuration lives. These options are primarily accessible to developers or operators.

With the RBAC MVP project, a new Console product is being introduced. It will centralize configuration and extend control to other roles in a learning instance, improving accessibility and governance.