Overview
The Alerts feature in fabric Copilot notifies you of potential issues using the data within your account. You can use these notifications to identify and respond to system errors or data anomalies that could impact business operations. For example, you can set up alerts for high order failure rates, abnormal dips in prices, published SKU counts dropping significantly, and transactional failures.
You can subscribe to receive alerts by email when an event occurs, and view alerts on the Alerts dashboard in Copilot. Users with shared access to your organization’s account can view the alerts you set up and optionally subscribe to them.
Setting up and configuring alerts requires Administrator privileges in Copilot. For more detailed information on these settings, see Role-Based Access Control.
Use Cases
Common use cases for alerts within fabric’s applications include:
- Orders: Alert that flags orders that might negatively impact trailing metrics, such as returns and cancellations.
- Inventory: Alert that creates a notification for any issues updating your inventory records.
- Product Catalog: Alert that creates a notification whenever a product information import fails.
Alert Components
Creating an alert involves setting up three main components: the Alert trigger conditions, Look-back period, and Severity threshold.
Alert Trigger Conditions
Alert trigger conditions consist of a series of statements that define the circumstances that trigger an alert. In these statements, you establish the components of an alert by selecting a fabric application, a service within that application, an attribute of that service, an operator, and a value for which you would like to set up the alert. When configuring these statements, you can use a variety of parameters, such as order statuses, inventory levels, and transaction outcomes, to create customized trigger conditions that meet your specific monitoring requirements.
It’s important to note that when you are setting up an alert in Copilot, the values displayed in each field are entirely dependent upon the selection in the previous field.
The following table outlines the fields in the Alert trigger conditions section, and their values.
| Field Name | Description | Values |
|---|---|---|
| App | The fabric application to set up the alert for. | - Orders - Inventory - Product Catalog |
| Service: | The service is the specific feature within the fabric application selected in the App field. | - Orders: Order, Invoice, and Allocation - Inventory: Inventory_imports - Product Catalog: Attribute, Bundle, Category, Product, and Collection |
| Attribute | Specifies a characteristic or property of the selection in the Service field. | Includes options such as: - createdAt: The time the service was created. - updatedAt: The time the service was updated. - statusCode: The service’s status code. |
| Operator | The Operator field describes the relationship between the Attribute field and the Add Values field. | - IN: Includes - NIN: Doesn’t include - EQ: Is equal to - NEQ: Not equal to - GT: Is greater than - LT: Is less than - GTE: Is greater than or equal to - LTE: Is less than or equal to |
| Add Values | The values represent specific states or conditions of the selected Attribute. | Time-based values include options such as: - NOW() - PT2H: The time of the attribute is within the last two hours. - NOW() - PT6H: The time of the attribute is within the last six hours. - NOW() - P2D: The time of the attribute is within the last two days. Status-based values include options such as: - ALLOCATED: Indicates a status of allocated for the selected attribute. - PROCESSING: Indicates a status of processing for the selected attribute. - FAILED: Indicates a status of failed for the selected attribute. |
Alert trigger conditions example
As an example of how you can use the fields in alert trigger conditions to create statements, consider the Payments Failure Alert template. It’s an alert that’s generated from the Orders application whenever an invoice fails.
There are two statements required to create this alert; an if statement and an and statement. The if statement simply says, “if the Orders app invoicing service created an invoice more than two hours ago.” To create this statement in the alert trigger conditions, the if statement is configured as follows:
- App: is set to Orders
- Service: is set to Invoice
- Attribute: is set to createdAt
- Operator: is set to GT
- Add value: is set to NOW() - PT2H
This statement tells Alerts where to look and when, but what it’s looking for - the failed invoice - is incomplete. The and statement finishes the alert trigger condition by describing the type of invoice to look for. It says, “the status of the invoice includes the values _failed_ or _settlement failed_.” To create this statement in the alert trigger conditions, the and statement is configured as follows:
- Service: is set to Invoice
- Attribute: is set to statusCode
- Operator: is set to IN
- Add Values: is set to FAILED and SETTLE_FAILED
Understanding alert trigger conditions is crucial for setting up effective alerts in your fabric applications. By configuring both if and and statements, you can specify the exact conditions that trigger an alert.
Adding and removing conditions
When creating an alert from scratch, you can refine your alert trigger conditions by adding and statements. This allows for even more nuanced and targeted alerting, so that you can specify combinations of attributes, operators, and values that must be met to trigger an alert. However, every condition for all your statements must be met to trigger the alert, which means too many and statements could cause you to miss an event that you want to monitor.
Look-Back Period
The look-back period is the timeframe that fabric considers when assessing data for potential alerts.
For instance, if an alert is configured to trigger when order processing times exceed a certain threshold, the look-back period could be defined as the past 24 hours. In this scenario, fabric examines order processing times over the last day to determine if the current processing time deviates significantly from the average.
Configuring the look-back period helps provide context to alerts. A shorter look-back period may capture recent changes or sudden spikes in activity, while a longer look-back period can help identify sustained trends or recurring issues.
Severity Threshold
The Severity threshold is the term for the required number of events to occur for an alert to be considered low, medium, or severe.
-
Low Severity: Alerts with a low severity threshold are triggered when the specified event occurs infrequently. These alerts typically highlight events that might require attention but may not be of immediate concern.
-
Medium Severity: A medium severity threshold indicates a moderate frequency of the event. Alerts in this category often point to events that may warrant closer monitoring due to their increased occurrence as a potential issue that should be addressed.
-
High Severity: Alerts with a high severity threshold are triggered when the specified event reaches a significant frequency. These alerts usually require immediate attention, as they typically signify critical events or issues that require prompt resolution to prevent impact on business operations.
You can configure the severity threshold numbers to tailor alerts to your specific needs.
Keeping with the example of the Payments Failure Alert, you could set the Low Severity field in this template to five. This will generate a low severity alert when five payments have failed within the time frame you specified. From there, you could set Medium Severity to 10, so that a medium severity alert would be generated when 10 payments fail within your time frame. Setting High Severity to 15 would generate high severity alert when 15 payments have failed within your time frame.
You will need to adjust the severity thresholds until you get the alert dialed in to your needs. Typically, you want to avoid infrequent or minor events and focus on frequent and severe events. Adjusting the severity threshold will help you strike a balance between being notified of potential issues and avoiding unnecessary alert fatigue.
Templates
You can use templates to set up alerts quickly without having to configure each trigger condition manually. These templates have pre-configured trigger conditions for common operational events, such as failed payments. With the predefined triggers for situations that often require immediate attention, you can address potential issues before they escalate into bigger problems.
Related Topics
Was this page helpful?