TL;DR

The Open edX platform needs a robust, user-friendly notifications system that includes an authoring tool for creating notifications and receiver tools for delivering them to users. The system should be flexible, enabling diverse user roles to send and receive the right notifications at the right time, through the channels that best suit their needs.

Problem

While a lot of what we need in order to add notifications to the Open edX platform already exists (e.g. the edx-platform notifications app, notifications tray etc), there’s one critical piece missing: a notifications admin interface that allows users to both author custom notifications, and manage automated notifications. Currently, notification authoring is managed in the code, making it inaccessible to course teams and non-technical staff.

Overview

Adding a notifications admin interface to the platform will enable anyone with the appropriate permissions to create, categorize, schedule, and send targeted messages to all users—or to specific subsets of users via the user grouping feature—across the platform, within an organization, or in a course. Among other benefits, this will allow course teams to deliver targeted interventions to learners who need support.

The interface would also support the configuration and control of automated notifications—those triggered by course activity, Aspects events, or other system-generated triggers—giving platform and course administrators greater flexibility over which automated notifications are sent to users.

The notifications system will support multiple delivery channels (web, email, and push notifications), and give users the power to opt in or out, specifying the type(s) of notifications they’d like to receive. The system will keep user data and communication channels secure, and ensure that user privacy is respected in line with global data protection regulations.

This proposal explores how to design and implement a flexible, user-friendly notifications system that integrates cleanly into the existing Open edX ecosystem.

Approach

Where possible, we’ll leverage work done on related projects within the community, such as the notifications tray and mobile notifications. The intention behind this is not only to create a consistent user experience across the platform, but also to reduce the design and development effort required, and simplify maintenance by sharing the same code as much as possible. By aligning with established components and UX patterns, we aim to deliver a seamless experience for both administrators and end users.

Use Cases

• As the Open edX Platform…

  • I want to send notifications to all users or specific subsets of users, to inform them of platform changes, community news, updates, and events, so that they are so that they are kept updated, and feel a part of the Community.

  • I want to urge users to provide platform feedback (via the forum) to help improve features, and encourage communication within the Community.

  • I want to add the notifications feature via a plugin slot, so instance managers can easily enable or disable the feature.

  • I want to view reports on user engagement with notifications, including open rates, click-through rates, and user preferences, so I know which notifications are valuable, and which aren’t.

• As an Instance Manager…

  • I want the ability to turn the notifications feature off or on depending on the needs of my instance.

• As a Course Delivery Team…

  • I want to be able to communicate with all learners or a specific subset of learners, so that I’m able to provide feedback/encouragement/resources to keep them engaged in their coursework, and to help them succeed.

  • I want to send targeted interventions to specific groups of learners, so that I can provide assistance at critical points in their educational journey.

  • I want to draft, edit, schedule, set recurrence and expiry, preview, and delete notifications, so that I have full control over which, when, and how notifications are delivered to users.

  • I want notifications within the LMS and Studio to work in a similar way, so that the user experience is consistent.

• As a Learner…

  • I want to receive relevant updates and reminders for my courses, assignments, and deadlines, so that I don’t miss important milestones.

  • I want to receive notifications about my grades, so that I can keep track of my progress.

  • I want the notifications I receive to be grouped, so that I am not inundated with similar notifications.

• As any User…

  • I want to manage the type and frequency of the notifications I receive across all channels (web, email, mobile, etc) centrally in my account settings, so that I can adjust my preferences in one place.

  • I want to receive short, easy-to-read notifications, so that they don’t take up too much of my time.

  • I want the ability to filter, open, dismiss, opt in/out, and mark as read/unread notifications, so I can organize my notifications inbox effectively.

  • I want to receive notifications in my preferred language, to save time and limit cognitive overhead.

  • I want to receive notifications about relevant forum activity, so I can keep up-to-date on responses, comments, questions etc.

  • I only want to receive an automated notification once, so that I am not inundated with duplicate notifications.

  • I want to view my notification history, so that I may refer to notifications I received previously.

  • I want to be notified about new and upcoming features, integrations, and platform improvements, so I can enhance my use of the Open edX platform.

  • I want to be informed of events and other developments in the community, so I can be more actively involved. 

  • I want to provide feedback on new features and integrations, so I can help improve the platform.

  • I want my preferences for email notifications to be updated should I unsubscribe from within the email client, so that I don’t have to unsubscribe in two places.

Desired Functionality Per Role

Core Notification Properties

Sources

• Authored notifications

  • Ad-hoc notification 

  • Scheduled notification

  • Recurring notification

  • Event-based notification (e.g. send welcome notification when learner enrolls in a course)

  • Time-based notification (e.g. upcoming assignment, overdue assignment)

• Automated notifications 

  • Account-related notifications

  • Third party notifications

    • Forum notifications (e.g. new post, new reply)

    • Aspects notifications (e.g. last visited, learner engagement)

Channels

Each notification has 1 or more channels:

• Notifications tray

  • LMS

  • Studio

  • Notifications admin interface

• Email

• Push notifications

State

• Read / Seen

• Unread / Unseen

• Dismissed 

• Expired

Content

• Timeframe: Indicates when the notification was generated

• Category: A tag indicating what category the notification pertains to

• Notification: A short but informative description communicating the main message

• Status: An indicator to help users see which notifications they’ve viewed

• Icon: A visual cue representing the type of notification

• Rich media (images, videos, links) (optional): e.g. direct URL to related content (e.g. Google Form for collecting user feedback)

Actions

• View / Open

• Mark as read / unread

• Dismiss

• Opt in / out

• Filter

Notification Display

Notifications will be delivered to users through multiple channels: a notifications tray (in the LMS, Studio, and potentially the admin interface if separate from Studio), push notifications, and email. Factors such as message length, user preferences, and context should guide the choice of delivery method. Typically, admin users will select the delivery channel when authoring each notification.

Notifications Tray

We plan to build the notifications tray on the foundation contributed by 2U, adapting it for the Open edX platform. Regardless of where we add the tray, it should work consistently to ensure a seamless user experience. The tray will enable users to access their notifications from any page within the interface without interrupting their workflow. When opened, it will display a list of notifications, with the most recent appearing at the top.

The status of notifications in the tray should be synchronized globally—if a user marks a notification as “read” in one location, it should appear as “read” across all notification trays accessible to that user.

To reduce notification fatigue, notifications will be batched. This means multiple notifications will be grouped into fewer, consolidated messages delivered at scheduled intervals rather than sent individually. Batching helps minimize interruptions and lowers the cognitive load caused by a barrage of alerts.

Push Notifications

Push notifications help ensure users stay informed with timely updates, news, or alerts, even when they’re not actively using the platform. When a user opts in to push notifications, they’ll receive them directly on their device—whether mobile or desktop. We’ll coordinate with the mobile notifications team to ensure consistency between the web and native apps. 

Email

In addition to the notifications tray, we hope to leverage the work the community has already done on email notifications. Users can tailor how and when they receive emails for notification activity. They can choose to receive email digests, which provide periodic updates if they haven’t visited the LMS or Studio recently. For more immediate updates, users can choose to be notified by email about new forum posts, replies, mentions, or activity in watched topics or categories. All email preferences can be easily managed in the user’s account settings, including the option to unsubscribe from specific notifications or disable emails entirely.

Note: This proposal aims to address several limitations in the current implementation of forum notifications. For example:

• Currently, course staff don’t receive notifications for forum activity unless they’re the original author or have manually followed each thread. This creates extra work and increases the chances of missing important conversations.

• While users have the option to receive daily or weekly email digests, there is no option to receive emails for all new posts. This is a standard feature of most forums, and we believe users would find it useful.

Custom vs Automated Notifications (TBD)

Notifications Admin Interface

It’s become apparent through work on other proposals that the Open edX platform requires some form of Global Admin Console. It may make sense for the notifications admin interface to live within this console once it’s been built. For the purposes of this proposal, we’ll assume that the Global Admin Console will exist independently from Studio and the LMS.

The notifications admin interface will offer authorized users a straightforward way to create, update, categorize, schedule, preview (in all available languages), and delete notifications. It will also support setting recurrence and expiry dates, as well as limiting the number of times a scheduled, recurring, or event-triggered notification is sent, preventing users from receiving duplicate messages.

Users will have the option to either create notifications from predefined templates or craft fully custom messages. To ensure clarity and readability, the admin interface will include guidance on writing concise and readable notifications. It will encourage users to stick to the following notification guidelines:

• Notifications should not feel “spammy”

• Notifications should be rare and special

• Notifications should be 1-2 sentences, and readable in 2-3s

• Notifications should be actionable (e.g. forum notifications should link to the appropriate place in the conversation, exam deadline notifications should link to the correct subsection, etc.)

Beyond custom notifications, admins can also control which automated notifications users receive (automated notifications are those triggered by course activities, Aspects events, or other system actions).

The interface will allow admins to send notifications to all users or targeted subsets of users (including individual learners) across the platform, within an organization, or in a course. Furthermore, admins can select the preferred delivery channels for each notification, choosing from the notifications tray, email, or push notifications.

Technical Approach

When evaluating the need to send notification to a designated group of users we see the need to:

1. Have a way to track and configure notification, this will deal with opt out policies and to have a way of adding configurations, which help us to know which app is triggering the notification using which channels and for which users.

2. Have a way to actually send out Notification, for now edx-ace is doing the job.

If we see right now in the edx-platform we have Notification app which is doing the job of configuration of Notification and creating opt-in/out policies. Most of the notification configuration are hard-coded.

The eventual goal as pointed by various section is to create a Notification Authoring System the hard-coded messaged and configuration can be generated by the staff. Not just that but this should also have the ability to send targeted notification to user groups. This can be done by extending the Notification app to support these functionalities and have a way to have a user facing component either within edx-platform or as an MFE.

But to evaluated this possibility we can also have a pilot where we can modify frontend-app-communication, where we can add a field to send emails to selected users or groups. These groups can be either dynamically fetched from Aspects like At-Risk learners.

UX/UI Approach (TBD)

• TBD based on how this proposal evolves.

Phases (TBD)

1. Notifications MVP

   • MVP Option 1 (if aiming for an Ulmo release)

     • Add the 2U implementation of notifications as is, making only the required adjustments

     • Iteratively add improvements and new features

   • MVP Option 2 (if aiming for an Ulmo release)

     • Use Aspects reports and bulk emailing to enable targeted interventions for at-risk learners 

   • MVP Option 3 (if aiming for a Verawood release)

     • Notifications Admin Interface (v1): Simple dashboard for creating and managing notifications

     • Consider using the user grouping methods that currently exist on the platform (listed here), and replacing with the new user grouping feature when released

       • Note: The user grouping feature will be released before the legacy user grouping mechanisms are migrated over to user grouping (currently targeted for a two-phased release in Ulmo and Verawood)

     • Prioritize in-platform notifications for user interventions first

2. Notifications Admin Interface (v2)

   • Adds functionality for sending notifications to user groups

   • TBD

3. TBD

4. etc…

Anticipated Effort

• TBD based on how this proposal evolves.

Usability Testing

Usability testing will take place at key stages throughout the implementation. Feedback will be gathered, reviewed, and shared with the Community, and any necessary adjustments will be made to enhance the feature based on those insights.

Competitive Research

Notifications in other learning platforms:

• Canvas

  • Although Canvas has a number of tools for instructor-to-learner communication, it doesn't seem to offer platform-to-instructor notifications within the admin interface.

• Moodle

  • Moodle has various tools for instructor-to-learner communication, but doesn't appear to have platform-to-instructor messaging within the admin interface.

• Coursera

  • Although Coursera offers a few tools for instructor-to-learner communication, it doesn't seem to provide platform-to-instructor communication within the admin interface.

Other notification examples:

• WordPress

  • WordPress displays a newsfeed on the homepage dashboard.

  • Notification Master (WordPress plugin)

• Mailchimp’s Campaign Builder

• Slack, Mattermost

• Pushwoosh

• Oracle Cloud Service Notifications Administration

• Further examples to be researched during the design phase (Jira / Confluence / forums / e-commerce notifications)

Implementation Plan

TBD. This proposal will require resourcing if accepted.

Long-term Ownership/Maintainership

TBD. Once the proposal is approved and resourced, we’ll determine who will be responsible for the ownership and long-term maintainership of the features outlined in this proposal.

Open Questions

1. Would it be important / possible to release an MVP in Ulmo? Or would it be better to release a more extensive v1 in Verawood (June 2026)? 

2. How far along is the RBAC project? Do we have a sense yet of which roles it would make sense to design notifications around?

3. Is the value of an admin panel worth the effort it will require to build (considering what we have in mind for custom vs automated notifications)?

4. Should the notifications admin interface exist within the Global Admin Console proposed here? (Currently the assumption is that the global admin console will exist independently from Studio and the LMS)

   1. If so, should the notifications tray appear in Studio and in the notifications admin interface?

5. Can we reuse any of the UI from the notifications tray?

   1. If not, what does the existing panel mentioned in this comment look like?

6. Should notifications be tailored to the Open edX release the user is working on? If so, how?

7. Localization:

   1. How do we allow for localization from the outset, but keep the initial scope slim?

   2. Ty had the idea of allowing authors to preview notifications in all available languages before sending. What would this look like in the admin? Would there be a field for each language where the author would manually input the translated text for each notification?

8. Do we need to support separate authoring mechanisms for each delivery channel, to account for the differences in formatting capabilities — for example, rich formatting in email vs. the more limited formatting in push notifications?

9. Reporting:

   1. Does anything exist in 2U’s notifications feature today that allows admins to view reports on user engagement with notifications (open rates etc)?

   2. Is this data users expect to see out of the box in the core part of the platform? Or do we expect technical users/instance operators to want to be able to pull this data from the tracking logs and view the data in their own custom reports?

   3. Is this data we provide in aspects as an out of the box aspects dashboard for instances that have aspects installed? Or is it this its own reporting tool?

10. Where/how are the “rules” for automated notifications set? (example of a rule: If a learner receives a “come back to the course” message after being inactive for 10 days, they should not receive another if they return briefly and go inactive again).

11. Should direct messaging be part of this proposal, or should we rather encourage users to use the forum for sending and receiving DMs?

12. Should we consider onboarding tools like Appcues or Chameleon for pointing out new features in the platform, or should this be done using the notification feature?