Goals
Expand NiFi bulletin functionality to inform users about all flow related matters and improve general communication through more immediate feedback on actions they perform.
Background and strategic fit
- Users must look in different UI locations depending on the source of a bulletin
- System-level bulletins highlight the icon in the flow status bar
- Component-level bulletins are only visible on the component itself or within the bulletin board
- Component-level bulletins can go unnoticed if the user is not operating within view of the affected component
- Regardless of a bulletin’s significance, it is communicated the same way; therefore, it could be said those of particular importance are not given enough attention
- There are many cases where NiFi should provide or can improve messaging related to other data flow matters, as well as general feedback on user performed actions 1 – all of which bulletins do not cover
- Awareness and acknowledgement of bulletins is not user specific
- Multiple users operating the same flow can have incomplete pictures of a data flow’s health and status
1 
Assumptions
- List the assumptions you have such as user, technical or other business assumptions. (e.g. users will primarily access this feature from a tablet).
Requirements
| # | Title | User Story | Importance | Notes |
|---|
| 1 | Short identifier for the story | Describe the user and what they are trying to achieve | Must Have | - Additional considerations or noteworthy references (links, issues)
|
| 2 | | | | |
User interaction and design
Introduce an enhanced system called Notifications that will provide:
- A single location where a user can see if there are any flow related issues
- Expanded highlighting of issues in specific areas as they occur, as is currently done on canvas components
- A count next to a notification icon indicating how many are active/unresolved
- A summary of active/unresolved notifications on hover and an action to access all notifications
- A Notifications area (currently Bulletin Board) – accessed by clicking the notification icon – expanded to allow searches by component name/type, notification type, etc.
- A tiered approach to UI behavior and required user interaction depending on the type of notification – see Importance levels detail table
- Notifications in real time as they occur and are resolved
- Additional context and relevant help for users to better understand and resolve issues
- Effective handling of notifications across multiple browser tabs 2
Changes to UI elements under proposed solution:
| Current Element | Replace With |
|---|
"Bulletin" (term and icon) 
| Notification 
|
| "Bulletin Board" (menu option) | Notifications |
| "Bulletin Level" (configuration label) | Notification Level |
A user will receive notifications and interact with them in one of three ways. This will depend on an importance level assigned to all notifications.
Importance levels detail:
| Importance Level | UI Behavior | Required User Interaction |
|---|
| Low | - Notification icon highlights
- Notification count updates
| None |
| High | - Notification icon highlights
- Notification count updates
- Prominent message appears on screen for ~3s
| None |
| Critical | - Notification icon highlights
- Notification count updates
- Prominent message appears on screen
| Message requires user acknowledgement to remove
(e.g., "Dismiss", "View details," "Check configuration", etc.) |
Importance levels will not be configured by the user. They will be programmatically set to prescribe a way for users to be informed of and interact with a specific notification.
The current Bulletin Level setting – to change to Notification Level under the proposal – consisting of debug, info, warn, and error will map to an importance level. This way, users will remain in control of what system/component-level notifications are emitted.
Examples of how notification levels would map to an importance level:
| Notification Level | Importance Level | Usability Notes |
|---|
| Debug | Low | Not necessary to interrupt user's workflow |
| Info | Low | Not necessary to interrupt user's workflow |
| Warn | High | Useful to immediately inform via on-screen message, but allows user to continue working at their discretion |
| Error | Critical | Reserve for serious conditions when immediate attention is necessary to maintain data flow health |
2 
Example Use Cases
- A new flow or component version is available (upgrade)
- A flow version has been removed or tagged as obsolete
- Registry connection status interrupted
- Expensive framework tasks 3
- Remote port connection status changes
- Backpressure engagement on connections
- Penalized flowfiles in a queue 4
- Startup errors 5
- Disk/repository space issues
- Cluster status changes
- When other users make changes to a flow
- Notify user when other systems/integrations affect NiFi
- New or updated schema available
3 
4 
5 
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|
Should NiFi maintain a history of all notifications independent of the standard 5m window? To what level of detail?
Some possible options:- User configurable time window (to see notifications via the UI)
- Write to a separate rolling log
| Communicate the decision reached |
Not Doing
- List the features discussed which are out of scope or might be revisited in a later release.