Configuring account inactivity rules
Account inactivity rules trigger data anomaly (DA) issues to alert you when account data has not been captured according to an expected schedule.
Before you begin
Create notification contacts for Inactivity Alerts in all locations where you want issues to be assigned to a specific user. For more information, see the related link.
Procedure
To create an account inactivity rule, right-click a meter in the Accounts grid, or on any account dashboard click More > Inactivity Rules >.
In the Create New dialog, complete the fields:
Event name
E.g., Account Inactivity Alert
For Account
This field is not editable and refers to the account that you are creating the rule for.
Set Status
This field determines the priority of the alert and issue to be created. It also impacts which notification contact, if any, is assigned to the issue and receives a notification email.
When data is older than
This field records the number of days, weeks or months from the last day of data for the account before a DA Issue will be created. For example, if you have a utility account that normally captures data every 3 months, you may set up an inactivity rule to raise a DA issue if data is older than 4 months.
Managing account inactivity data anomaly issues
When an inactivity rule condition is met, the system checks whether there is an existing unresolved issue for the rule:
If there is no issue, then a new issue is created and assigned to the appropriate notification contact or to an internal system user if a notification contact does not exist. Depending on your organization settings, an email notification will be sent to the notification contact.
If there is an existing unresolved issue, then an alert is logged on the existing issue. To prevent email flooding, notification emails are not sent out for subsequent alerts.
An account inactivity DA issue is similar to other DA issues but provides some additional features:
The issue will display the current alert status based on the last day of data for the account. This is useful for filtering out accounts where data has been captured after the issues were generated.
If there is sufficient historical data, the issue will display whether data is typically captured manually or via connector, and how frequently it is captured. This is useful for identifying where connectors or integrations are the root cause of the problem.