diff --git a/beps/0001-notifications-system/README.md b/beps/0001-notifications-system/README.md
index 4b4f3b0532..fb3e36f624 100644
--- a/beps/0001-notifications-system/README.md
+++ b/beps/0001-notifications-system/README.md
@@ -110,6 +110,7 @@ The notification backend stores notification using the [database service](https:
   - Topic (optional)
   - Scope (optional)
   - Icon (optional)
+  - Extra (optional)
 
 The recipients is **not** a list of users, but rather a filter that describes who should receive the notification. It must be possible to evaluate this filter in a database query, so that we can efficiently fetch all notifications for a given user. The same filter will also be used by the signal backend to determine which users should receive a signal.
 
@@ -147,6 +148,8 @@ The link is a relative or absolute URL. As an example, it can be used:
 - by an external system to request an action within an asynchronous task
 - by a BE plugin to provide link to other part of the Backstage UI (i.e. to the Catalog)
 
+The extra is a flexible JSON like field, where an additional payload can be stored.
+
 The additional links are an array of title-URL pairs. They can represent immediate actions on the notification (i.e. yes-no) or lead the user to additional details.
 
 The `notification-backend` does not provide any new permissions, since creating notifications can only be done by other backend plugins, while reading notifications can only be done by the authenticated user. It is possible that we want to add a permissions for reading notifications, in particular for admin and impersonation use cases, but that is not part of this proposal or the initial implementation.