Open edX for universities and online programs

A degree or certificate program is usually modeled as a set of courses, the rules that decide who may enroll in each course and in what order, and the credentials awarded when a learner meets defined requirements. Open edX gives you the building blocks for the first and third parts: courses, course runs, enrollment and certificates. It does not ship a finished degree or program model that matches a university's academic rules. Before any build starts, confirm with the registrar and the academic units how a program hierarchy, prerequisites, credit hours and credential rules will be represented, and whether they live inside Open edX, in the campus student information system, or in a catalog layer between the two. That decision shapes almost everything that follows.

Inside the platform, the course is the unit that course teams author. Studio, the authoring application, holds course outlines, sections, subsections, units and the components placed in them. The LMS presents the same course to learners and the instructor dashboard gives course staff views of enrollment, progress and grades. Verawood, the current named release, added a new Studio sidebar, tagging and taxonomy management, and a redesigned instructor dashboard. Tagging and taxonomy features can help course teams label content consistently across a large catalog, but the taxonomy itself is a design choice. Decide the vocabulary with the academic units first, then confirm whether the tags will be used for discovery, reporting or both, and who has permission to create and change them.

Course team workflows need the same care as the data model. Map who authors content, who reviews it, who publishes a course run and who can change a live course without disrupting learners. Studio roles and course staff roles are separate concerns, so confirm which faculty, instructional designers and teaching assistants need which access, and how that is granted when identities come from the campus directory. Plan a naming convention for course runs and a process for retiring them, because credentials issued against one run must still make sense years later.

Credentials add the final layer. Certificates in Open edX are tied to course and run settings, and program-level credentials, such as a certificate awarded only after a set of courses is complete, need a rule engine or a record kept outside the core course structure. Ask the registrar which credentials must appear on a transcript, which must be verifiable by third parties, and who signs off on award criteria. Confirm the exact certificate and program-award options available in the Verawood release and in your chosen distribution before promising any of them to academic units, and record every rule that is implemented outside the platform so it can be audited later.

Finally, treat the program design as a document to validate, not a configuration to discover during build. Produce a written mapping of programs to courses, course runs to terms, enrollment rules to eligibility sources, and credentials to award criteria, then review it with the registrar, the academic units and the team that will maintain the integration. Gaps found at this stage are cheap to resolve. Gaps found after learners have enrolled require data corrections and, sometimes, reissued credentials.

The two integration paths are separate, but a decision in one changes the other, so the team should settle the learner record before writing any configuration. SAML federation handles sign-in: students and staff authenticate once against the campus identity provider and arrive in Open edX. LTI handles delivery: the campus LMS launches a course hosted in Open edX and passes the learner's identity and role along with the launch. Both paths touch the same person, so both must agree on who that person is. The first decision is which system owns the learner record. In most universities the student information system or the campus identity store is authoritative for enrollment and identity, and Open edX holds a provisioned account that is linked to it. Name the system of record for each field, including username, email, legal name and enrollment status. Then decide the matching key. Open edX third-party authentication can link an incoming SAML assertion to an account, but a mutable attribute such as an email address is a weak key if addresses change. Ask the identity team which persistent identifier the IdP releases and confirm it in the attribute release policy.

Next, map identity provider attributes to Open edX account fields in a written table. Each row should name the SAML attribute, the account field it fills, whether it is required at first login, and what happens when it is missing. Include the rules for accounts that already exist from earlier pilots or manual enrollment, because duplicate accounts are the most common cleanup task after federation goes live. Decide who can change a mapping after launch and how that change is tested. Staff accounts should follow the same mapping as students, but role assignment in Studio and the LMS should come from a separate, reviewed list, not from a single attribute value. LTI is the second path, and it introduces its own choices. The campus LMS sends a signed launch that carries the user, the course context and roles. Open edX must map those roles to learner or course team permissions and must reject launches it cannot verify. If the campus LMS supports grade return, decide whether the LMS or Open edX holds the gradebook of record, which assignments return scores, and how late corrections are handled. Where grades or other education records are disclosed to a campus system, the institution's FERPA disclosure record duties under 34 CFR 99.32 still apply, so log those flows.

Before design starts, get three things confirmed in writing: the LTI version and certification level that the planned Open edX release supports, the specific LTI services the campus LMS vendor supports for your tenant, and the vendor's commitment to support that combination. Open edX Verawood added LTI Advantage Complete certification, but certification is a release-specific claim, so confirm the level for the version you intend to deploy rather than assuming it carries over. A vendor that supports only part of the launch or grade services will change the design, so this check belongs at the start. A practical sequence is: name the record owner, write the attribute map, define launch and role mapping, define grade return, then test in a staging environment with a test identity provider and a test LMS tenant. Verify a first-time login, a returning login, a missing attribute, a launch by a learner and by a course team member, and a grade returned after a change. Plan for the risk that a vendor upgrade changes LTI behavior, and ask the campus LMS team to notify you before their changes reach production. Document each decision so the operations team can explain any account or grade discrepancy later.

The build cannot settle scope until the university names its decision-makers and supplies six inputs: owners for each program, the campus identity provider and its metadata, the campus LMS and its LTI contacts, records retention rules, accessibility requirements, and a decision-maker for data sharing. Each one sets a boundary that the design depends on. Gaps do not usually stop the work outright. They push decisions into the middle of the build, where rework is more expensive. Start with named owners for each program. A MOOC, a credit-bearing degree and a certificate series each need an accountable academic owner who approves course structure, credential rules, enrollment terms and learner-facing policies. The build team needs that owner to decide what the catalog contains and which credentials the platform issues. Without a named owner, these questions stay open, and the course team workflow in Studio is designed around guesses. Ask the university to confirm one owner per program and one technical owner for the platform.

The campus identity provider drives the single sign-on design. Open edX third-party authentication supports SAML 2.0 and Shibboleth, so the university must supply its SAML metadata for test and production, the attributes it releases for each learner (a stable identifier, email and name at minimum), and the rules for linking existing accounts. Ask the identity team which attributes they release by default and whether a federation agreement governs release. If metadata arrives late, login cannot be tested end to end, and the attribute mapping and account-linking decisions remain unverified until late in the build.

Delivery into the campus LMS runs over LTI, so the build needs a contact who administers that LMS and can register an external tool. That person must confirm which LTI version the campus LMS supports, supply the launch and redirect URLs for each environment, agree on the exchange of keys and secrets, and state how learner roles map onto course roles. Grade return is the hardest part to settle. If the LMS admin is not named, the tool cannot be registered in a test environment, and the decision about whether grades flow back to the campus gradebook stays unmade. Confirm both the LTI version and the grade-passback expectation in writing before design starts.

Records retention and data sharing need the most careful assignment. FERPA allows an outside contractor to hold education records as a school official only when the institution keeps direct control over their use and maintenance, and FERPA requires a record of each disclosure for as long as the records are kept (34 CFR 99.31 and 99.32). The university should name a decision-maker who approves what the platform and any analytics pipeline share with third parties, and who sets how long learner activity, backups and disclosure logs are retained. If learners under 13 may enroll, the COPPA retention rules in 16 CFR 312.10 also apply. Without this decision-maker, the analytics and backup design cannot be finished. Accessibility requirements close the list. The university should state the conformance target it must meet, cite the rule that binds it (for example, the web accessibility provisions in 28 CFR Part 35 Subpart H if it is a public entity), and name who signs off on accessibility testing. These choices shape the theme, course templates and frontend work. Without them, acceptance criteria stay vague, and the team cannot tell when the work is complete.