paulasilvatech Backstage notifications
Deliver user-facing messages through the notifications service, not as inter-process messaging.
When to invoke
- "Add Backstage notifications and signals."
- "Send a notification from a backend plugin or template."
- "Configure email or Slack delivery."
- "Fix notification preferences or delivery."
Procedure
- Confirm Backstage version and frontend mode. Notifications and signals are included by default in create-app from Backstage 1.42.0, but navigation and settings may still require app wiring.
- Install or verify frontend and backend notification packages.
- Add the notifications page or sidebar item through the target frontend system.
- Use
notificationServicefrom@backstage/plugin-notifications-nodeinside backend plugins; do not call the REST API from a backend plugin. - Use authenticated REST calls only for external services.
- Choose broadcast or entity recipients and validate catalog entity references.
- Add signals only when near-real-time push improves the experience.
- Add processors for decoration or external delivery; keep post-processing failures observable.
- Configure user and default settings by channel, origin, or topic.
- For email or Slack, store credentials externally, scope access, and test throttling and routing.
- Test unread/read/saved behavior, preferences, signals, processor failure, and delivery to users or groups.
Output template
## Backstage notifications result
| Origin | Recipients | Topic | Processor | Signal | Validation |
| --- | --- | --- | --- | --- | --- |
### External configuration
- `<ENV_NAME>`: <purpose only>
Quality gate
- Notifications are user-facing, not inter-process messages.
- Backend plugins use the node service rather than their own REST calls.
- External emitters authenticate with least privilege.
- Recipients resolve to catalog users or groups.
- Processor credentials remain external and failures are observable.
- Preferences, signals, routing, and delivery are tested.