Alerts are monitors setup on top of your data defined via SQL. You can specify the frequency of monitoring your data, who and how to notify them when we detect new data.

Locale requires your data to be defined as a list, you can create this list with your business logic and conditions using SQL queries within Locale itself. Once you define the list to be monitored by Locale, we run your SQL query for the frequency provided and inform you when we detect new rows being added to the list.

A good practice to define the data to be monitored by Locale is as if the list should contain individual items that are actionable. Example, Delayed Orders, pending requests for more than x hours, SLA Breach by a partner, etc. Basically, each list item should be actionable and has all the information required in the same row.

So, let's get started with creating a new Alert in Locale!

Locale provides you with two different ways to define the list to be monitored using SQL. Using our No Code SQL builder or using an SQL Editor. If you are new to SQL and have little to no knowledge of writing SQL queries, you can choose the No Code editor. If you are familiar with SQL, you can go ahead with the SQL Editor to define the data to be monitored by Locale.

Once you are in the SQL Query editor, you can write an SQL Query to output a list which can be monitored by locale. Your SQL query can contain Business Logic and other conditions to help you fetch an accurate list that you want to keep monitoring. Think of this list as when an item matches a condition, it will be present in the list.

If you want to get alerts on delayed orders, your SQL query should ideally be fetching all the current delayed orders from your DB. Similarly, if you want to get alerts on SLA breaches, you should accurately filter and get the list containing all the current SLA Breaches. So as whenever we run this query, your list should always output the latest status list of items that matches the condition.

One thing to keep in mind is to make sure each row of your list has a column containing a unique value which can identify each row. If you are querying delayed order, order_id can be a unique row since there won't be multiple records for the same order in delays.

Once you are done with the SQL query to fetch the list, you need to monitor, you can click on done.

The second step, we need to select the column which can uniquely identify each row. Example, if you are fetching a list of orders, the unique value column would be the order_id, if you are fetching a list of users, the unique value would be user_id. We need to make sure the value in this column is not something that will change (eg. status).

Why do we need a unique value column? Locale uses the value in this column to match with existing results against new results on future runs to identify whether a new row is being added or an existing row has been removed. If you choose a column which is not unique, your alert might not give expected results.

Next up, we can configure how frequently we need to run the SQL query to monitor for new rows. Locale will run the SQL query on the frequency provided and check if new rows are being added or an existing row has been removed. Think of this as a new order is being delayed (when a new order details gets fetched in the list) or and order is being delivered (when an existing row is being removed from the list.

Locale provides multiple ways with which you can define the monitoring frequency. Either fixed interval or at a given time. You can choose a particular day of the week and time of the day to monitor the list. Locale will execute your SQL query and report to you whenever we find new rows being added to the SQL response.

Whenever Locale identifies new rows in your SQL query response. We create an Incident. An Incident is a report/thread for that particular new item being identified by locale. Each incident is a collaboration ground for your team to take action and talk about the issue. You can configure either you want an individual incident for every new row being added, or just one incident for all the new rows being added.

When should I pick an Individual Incident for each new row and one incident for all the new rows? We recommend our users to configure incidents such that you are taking action on an individual item as per your workflows. If you are a team where you need to take specific action on top of each delayed order / SLA Breach / Missed deadlines, you should ideally choose an individual incident for each new row. If you are a team where you have an alert which lists out delayed orders for a partner and have to take action on the partner, you should be ideally using One incident for all the new rows. In this way, you can get a list of all the delayed orders for a partner and take action to understand the issue with the partner.

In short, if you take action on an individual item, you need to use an Individual incident for each row. If you take action on a group of items together, you should choose one incident for all new rows.

After choosing the type of incidents being created, you can configure how an incident will look like. Each incident in locale has a set of properties

You can use the SQL query response within these titles and descriptions to enrich the data and make it personalized. Make sure you fetch all the necessary information for each item in the same SQL row so that it can be used to customize the titles and descriptions.

3. Priority of the Incident: Locale provides multiple priorities which can be used to denote the urgency of the incident being created. This can help your teammates to quickly act on incidents with higher priorities.

4. Assignees of the Incident: You can select the team and team members who are responsible for solving the incident. If you want assignees to be dynamic for each item, you can fetch the email of your assignee in the SQL response corresponding to each row, and you can use the dynamic assignee option to automatically assign your team members in locale with the email address.

If you are using dynamic assignment, make sure you query the email address along with each row and make sure you have already invited these team members to locale.

In case, we don't find a team member with a matching email address from the SQL results, you can choose a default assignee or the incident will go unassigned.

5. Escalations: You can also define a rule to escalate an incident to a different team member if an incident is not resolved within a specified time period. The user assigned for escalation will receive notification whenever an incident is escalated.

6. Automatic Resolution: Helps you to automatically resolve an incident created for a new row to be resolved if locale detects that the corresponding row is no longer present in the SQL response in future runs.

7. Automatic Labels: You can choose the labels to categorieze the incidents based on the data present in the SQL response. You can pick max 5 columns which will get added as labels for each incidents. Labels helps you to analyze and gather insights on how your alerts and teams are performing.

8. Suggested Labels: You can pick some of the existing labels already created in your organization to show to your team mates to choose from. This helps your team mates to quickly select a label from a list of suggested labels to be used for the incident. (These labels won't be automatically added to the incident, instead it will be shown as recommendation to your team members to choose form)

Locale provides a handful of options to choose from, to which we will send notifications whenever a new incident is created or an incident is escalated. You can click on + Add notifications / action button on the final step to get a menu of all the destinations' locale supports. If you want something that's not listed, you can contact us, and we will get it ready for you.

Locale will automatically add the emails of assignees and user to be escalated to in the notifications. You can add more users or remove these notifications simply by editing the notification item.

You can pick from the list provided and go on to configure the destination specific details to receive your notifications.

Apart from Email Subscribers, all the other destinations will receive notification/action only for new incidents being created or an existing incident being escalated.

Email subscribers will receive, not just the above-mentioned notifications, they will also receive notifications for new comments as well as the incidents.

Once you have confirmed all the details for your alert, you can click on Save Alert and your alert will start running. New incidents and notifications will be created whenever the alert/monitor identifies new rows being added to the list you configured via SQL.

Have more doubts? You can always contact us to get more information or clear your doubts.