Key Alerts are live notifications triggered during shifts to alert staff to shift related variance such as employees who haven't clocked in yet. Key Alerts are an optional account-wide setting.
How it works
Each Key Alert type has a configurable 'lenience'. This is an amount of time after which an alert is triggered
Key Alerts are received by users on the Mobile App
You can choose if you want to send key alerts notifications to managers, employees or admins
Enabling Key Alerts
To turn on key alerts, navigate to Settings > Notifications and tasks.
To turn an alert on, select the type of Key Alert and switch the toggle on for the role types you want to receive the alert:
When alerting the manager: managers of the respective employee who are currently clocked in will receive the alert through the employee app. If no managers are clocked in when the alert is triggered, all managers for the team are notified
When alerting the organisation admins: all of the organisation admins will be alerted
Setting Up Lenience
The lenience is the amount of time after which an alert is triggered. The minimum is 5 minutes and the maximum for the delay is up to 60 minutes.
For example, a lenience of 15 minutes on the 'Late to work' key alert will trigger an alert when an employee hasn't recorded a clock-in 15 minutes after their rostered start time.
Types of Key Alerts
Type of Alert | Triggered when... |
Late to Work | An employee hasn't clocked in after their rostered start time |
Late to Clock Out | An employee hasn't clocked out after their rostered finish time |
Didn't Clock Break | An employee hasn't commenced their break after their break start time |
Overtime Risk | When an employee finishes their shift for the day, Tanda will check if that employee has future scheduled shifts that will put them into overtime, and it will send the notification if they do. |
Qualification maximum hours risk | An employee exceeds the maximum working hours condition entered on a qualification. Learn more about our Qualifications feature in this article. |
FAQ's and Troubleshooting
Key Alerts are triggered from the Tanda cloud server and sent to a users device. Most Key Alerts should be received in real-time, but there are some circumstances where you might experience a delay or a notification that appears to have been incorrectly sent.
Use the Key Alert Report to confirm when the Key Alert was sent
If it's your first time using the Key Alert Report, you will need to turn it on by navigating to Settings > Platform > Platform Templates (Reports) and click the 'Key Alert Report' to activate the report. Once activated, you will find this report in the 'Anomaly Detection' section of your reports tab in Tanda.
The Key Alert Report shows an audit history of when Key Alerts were sent from Tanda to the user's device.
What to check if there is a long delay between the time the Key Alert was sent and when it was shown on an employees mobile device
The time stamp on the notification triggered from the Mobile App is the time that the employees mobile device first displayed the notification. This time can be delayed compared to the time it was sent from Tanda to the device.
There are several reasons a mobile device might have a delay before showing a notification. The most common considerations are:
The notification settings of the mobile device will need to allow the notification to be triggered
The Mobile App will need to still be running on the phone in order for a notification to be triggered. If the App has been force stopped, a notification won't trigger
Device power saving and data saving settings can delay the receipt of the Key Alert to the device
What to check if a Key Alert was triggered incorrectly
The most common reason for a Key Alert being triggered incorrectly is if the clock-in was not yet received by the Tanda server when the Key Alert was triggered.
This occurs if there is a connectivity issue that delayed the Time Clock App from sending the clock-in to the server. You can confirm if this is the case by looking at the Timesheet Audit History for the shift.
How to interpret the Timesheet Audit History:
1. Shows time the clock-in was received by the server in the 'time' column
2. Shows time the clock-in was recorded on the Time Clock in the 'changes' column
In most cases, there will be no difference between these two times as clock-in times are usually sent to the server within seconds of occurring. However if the device had internet connection issues at this time, you might see a difference between these two times. If the clock-in was received by the server after the Key Alert lenience, the Key Alert will still be generated as the employees shift status will not have been updated yet at this time due to the delay in receiving the time from the Time Clock.