Idea Title
Backend messaging and (simple) notifications
What is my idea about?
Better communication and collaboration in the TYPO3 backend as an evolution for the existing solutions:
System Notes
TYPO3 has long provided a simple way for backend users to “communicate” with each other through the System Notes (For Editors — TYPO3 CMS System Notes main documentation) package. This functionality is comparable to an advanced version of operating system sticky notes.
Users can create notes by defining a subject and message, assigning a category, and configuring access permissions. These notes are displayed directly within the Page module or listed via Dashboard widgets. Each note is always associated with a specific page, providing basic, page-related communication within the backend.
Notes field in record data
Records can also have a dedicated field that allows users to add a short description (row description). This field can be used to store basic information, such as explaining the purpose or intended usage of a record. However, this functionality is very limited and does not support structured or interactive communication.
What do you want to achieve by 30th of April 2026?
Messaging - new approach
Messaging is a next step (evolution) of TYPO3 backend users communication. It will not have limitations of System Notes by providing more features to the users, while keeping it simple to be used and easily maintainable.
Main features
This list describes the features that the new extension should provide.
- Works for admins and standard users (with some restrictions for the standard users)
Send message to a selected user (need to be within the same BE groups, admins can send messages to any user) - Group messages into threads, allow to response to thread message
- Add an option to require from the recipient to mark the message as acknowledged (to have confirmation that he not only read it, but also did some required actions)
Integrate with TYPO3 backend notifications modals (notify about new message - add an option to opt out for the users from this feature) - Allow to move the messages thread to an archive (only thread owner can do this - the one who sent first message)
- Record and Page context aware (need to respect access permissions)
- The list view for a record and record edit form will contain dedicated button with and message icon - it will allow to create a new message and connect it with the Record ID - the initialized thread will also link directly to the Record
- The Page view and Page edit form will contain dedicated button with and message icon - it will allow to create a new message and connect it with the Page ID - the initialized thread will also link directly to the Page
- Messages without Page or Record context are also allowed
- Floating, simple side panel in the TYPO3 backend to render messages, to avoid switching to a dedication module
- Messaging should be enabled to admins and users with required permissions (tables, modules etc.)
- Make it localizable (translatable) through Crowdin
- Create a base documentation
The final backend UI should be consulted with the UI/UX team to make sure that it follows current guidelines and aligns with the TYPO3 14 interfaces.
The created package will be published on GitHub and installable through Composer.
What is the potential impact of your idea for the overall goal?
How will it help users?
The messaging extension will provide TYPO3 backend users with a built-in, context-aware communication channel, tightly integrated into their daily editorial and administrative workflows.
Instead of relying on external tools such as e-mail, Slack, or project management systems, users can communicate directly where the work happens - on pages and records inside the TYPO3 backend. This significantly reduces context switching and the risk of losing important information.
Key benefits for users:
- Asynchronous collaboration - users do not need to be online at the same time. Messages and threads persist and can be read and continued later, which is especially helpful for distributed teams, part-time editors, or different time zones
- Contextual communication - messages are linked to Pages or Records. This means discussions, questions, or instructions are always visible in the exact context they relate to, making it easier to understand what needs to be done and why
- Reduced reliance on external tools - teams can keep simple editorial communication inside TYPO3, avoiding scattered information across e-mails, chat tools, or tickets that are disconnected from the actual content
- Improved handovers and continuity - for example, if one user edits a page on Thursday and goes out of office, they can leave a message directly on the page or record. A colleague logging in on Monday can immediately see the message (has a notification) in context and continue the work without additional explanations or searching through e-mails
- Non-intrusive user experience - messages are accessible via a floating side panel and users are notified through core flash notifications (when online) and through notification indicator, allowing users to stay informed without disrupting their current task or switching to a separate module.
- Better onboarding and collaboration - new team members can follow existing message threads attached to pages or records and quickly understand past decisions, open questions, or pending tasks (if the new user has proper permissions)
- Overall, the extension aims to make collaboration more transparent, efficient, and sustainable, while staying lightweight and aligned with TYPO3’s backend best practices.
Notifications
For the MVP, the notification system will intentionally remain lightweight. Its primary purpose is to inform users about new and pending (unread) messages.
Notifications will be displayed in the TYPO3 backend, for example via a bell icon with a visual indicator (such as a colored dot or counter) to signal unread items. When a notification is clicked, a floating side panel will open and display the relevant message thread or its details, allowing users to review and respond without leaving their current context.
To ensure future extensibility, a Notifications API should be introduced. This API will make it possible for other parts of the TYPO3 backend - or additional extensions - to send notifications to users in a consistent way, enabling further use cases beyond messaging in later development phases.
Implementation.
How does your Idea align with the strategic goals for TYPO3 v14.
The planned implementation targets TYPO3 14. As this version is not yet available as an LTS release and core developers are currently focused on other priorities, the functionality will initially be delivered as an extension.
Once the extension has been tested, stabilized, and adopted by the community, the long-term goal would be to consider it for inclusion as one of the cms-* packages. This wo
It aligns with the following strategic goals:
Strategic Goal 3 — Enabling Better Content: TYPO3 should efficiently integrate with external tools, enhance content creation experience and in system management and health monitoring.
Strategic Goal 4 — Improve Customer-Oriented Communication: Better backend user experience through clear best practices and in-system support.
Future development (not part of the MVP)
After completing the MVP scope, the extension may be extended further. Possible next steps include:
- Support message threads sent to a group of users (multiple recipients), where all selected users can read and participate in a shared thread
- Allow adding new users to existing message threads
- Integrate with the TYPO3 mailing system to send e-mail reminders to users who have unread or pending messages for an extended period of time (as a command executed by Scheduler)
- Provide a dedicated backend module for standard users to review active and archived message threads, including options to search, filter, and export threads
- Provide a dedicated administrative backend module to view and manage all message threads
- Extend the notification system by integrating additional backend areas and allowing further triggers
- Evaluate whether messages should optionally support simple task elements (for example, a lightweight checklist), while keeping the extension easy to maintain
Which budget do we need for this idea?
10000 Euro
My Name
Marcin Sągol