# What / Why
## What are we building, and why?
>In one or two sentences, d…escribe the customer or community need, and what impact it has if we don’t address it.
Users who have narrowed down on something in their Dashboards are frustrated that they have to have to leave the context that they are looking at to create an alert. The user should be able to manage alerts based on what they are looking at in context.
## What matters most to users & customers?
>Describe the most important customer benefits and needs. Highlight any research, proposals, requests, issues, forum posts, anecdotes that signal this is the right thing to build.
Users will improve accuracy and reduce cognitive load when they create alerts based on what they are looking at instead of moving to a separate plugin page. Users will also benefit from seeing an overlay of alerts fired when reviewing a visualization tied to an alert.
## What matters most to OpenSearch?
>Describe the value that this feature will bring to the OpenSearch community, partners, or the project.
Making it easier for users to setup alerts and feel more confident in the systems they are responsible for which would result in higher adoption.
## What does the user experience look like?
>Describe the product feature requirements/specification. You may include low-fidelity sketches or wireframes, APIs stubs, or other examples of how a customer would use the feature. Using a bulleted list or simple diagrams to outline features is okay.
* User narrows down what they are looking at (e.g. troubleshooting a problem, setting up new service) in a visualization within Dashboards.
* Technical folk will use the Alerting plugin interface.
* Non technical will take advantage of the dashboards they are accustomed to or have built.
* The user selects the secondary menu from the visualization drop down after creating a visualization on a Dashboard.
* The user is then shown a consolidated experience of creating a new monitor/alert where the form is pre-filled based on the context. If the user decides that they want to the normal monitor/alert flow, they will be sent over to the normal monitor/alert workflow with their visualization information filled in.
* Error handling will be handled within the consolidated creation view.
* Alert creation will be confirmed with a toast message on the dashboard.
* Create alert flow
* As a user, I want to be able to create an alert from a Dashboard visualization, so I can quickly create an alert based on what I’m looking at in the moment
* As a user, I want my “create alert” form to be a simple experience, so I can quickly setup an alert and not be overwhelmed by configuration options.
* As a user, I want my create alert form to be pre-filled in based on what I’m looking at, so I don’t fight to get the right information in when setting them up.
* As a user, I want to know if there are errors when setting up a new alert, so I can fix them on the form.
* As an advanced user, I want the ability to move to the normal alert creation flow and retain all my pre-filled information, so I can setup the alert just the way I want it.
* View alerts tied to visualizations
* If an alert is tied to a visualization, it is tied to the Saved Object
* Once an alert has been created, I want to be able to see it on the visualization, so I can easily view what is happening for a context I am interested in.
* If I am looking at a visualization, I want to edit an alert’s attributes, so that I save time by not going into the plugin.
* If the visualization is refreshed with a new timescale, I want to see alerts associated with the updated timescale.
Performance / Bench Marking
* Need to answer the following questions...
* How much additional time will it take to fetch alert finding data and what will that do to page load times?
* How will adding 100, 1000, 10000 new monitors to a cluster affect cluster performance?
* How will we be logging performance data for later consumption in logs?
Administration
* Default State (on)
* Turn on/off
* As an administrator who is concerned about users creating alerts in my system, I want to turn off the feature for all users, so I can rest easy that detectors are not using critical indexing resources
* If alerts in the visualization is turned off, no users will see the feature
* Performance
* As an administrator, I want a mechanism which will tell me monitors are taking up too much compute, so I can react before things get bad on my cluster.
* As an administrator, I want to know what monitors are using inefficient queries, so I can optimize performance.
* Access Controls ([Predefined Roles](https://opensearch.org/docs/latest/security-plugin/access-control/users-roles/#predefined-roles))
* As an administrator who wants to lock down their system, I want to know what predefined roles are required for displaying alerts on visualizations on dashboards
* Either for Dashboards
* opensearch_dashboards_read_only - A special role that prevents users from making changes to visualizations, dashboards, and other OpenSearch Dashboards objects.
* opensearch_dashboards_user - Grants permissions to use OpenSearch Dashboards: cluster-wide searches, index monitoring, and write to various OpenSearch Dashboards indices.
* Either for Alerting
* alerting_ack_alerts - Grants permissions to view and acknowledge alerts, but not modify destinations or monitors.
* alerting_read_access - Grants permissions to view monitors, but not create, modify, or delete detectors.
* alerting_full_access - Grants full permissions to all alerting actions.
* As an administrator who wants to lock down their system, I want to designate users/groups who can view alerts on visualizations in dashboards
* opensearch_dashboards_read_only + alerting_ack_alerts or alerting_read_access = can view monitors created by others
* opensearch_dashboards_read_only + alerting_full_access = can view monitors created by others
* opensearch_dashboards_read_only + alerting_read_access = can view monitors created by others
* As an administrator who wants to lock down their system, I want to designate users/groups who can create alerts on visualizations in dashboards
* opensearch_dashboards_user + alerting_full_access = can create dashboards and create monitors
* Role Conflicts
* If a user who does not have alerting_full_access or alerting_read_access is provided a dashboard link which has visualizations with alerting enabled, they will not be able to see them because they won’t have alerting permissions.
## Not included in the initial release
* Setting up many alerts..
* As someone who has to setup many alerts which are essentially the same thing, I want an easy way to mimic an alert’s details to make it easy to create new alerts
* Cross cluster support
* Discover support
* [Unsupported aggregations/features](https://opensearch.org/docs/latest/monitoring-plugins/ad/index/#add-features-to-your-detector)
