We’ve been hard at work on the TribeHR for iOS app for the past two years, and it came time to add push notifications to our list of features. Since our 1.2.0 release, we’ve allowed employees to request leave through the mobile app, and managers have the ability to review and approve leave requests on their phones, too. The obvious next step is to notify your manager when you request some time off!
In the past, we’ve sent out emails for this situation and many others. We notify you when you’ve received kudos, when you’ve been added as a participant to a goal, or when there’s a new applicant for a job posting that you’ve been assigned to as a reviewer.
We knew that we wanted to add push notifications for many of these situations, and that would mean revamping the way that we send notifications. So instead of just adding in code to send push notifications if the employee has the TribeHR for iOS app installed, we sat down and re-thought our approach to notifications. What other things do we think we might want to do later?
A lot of what we discussed focused on users’ preferences for notifications. We’ve all seen the standard grid of checkboxes: the list of notification-worthy events listed down the left side, and columns of checkboxes for “Email” and “Mobile” notifications. While the visual design can change easily, this is the bare minimum: “yes, I want to receive notifications about kudos via email,” “No, I only want push notifications for leave requests,” and so on.
But besides selecting which medium notifications should be sent over (email, push notifications, maybe others such as SMS in the future), we came up with a list of other things over which it might be interesting to allow control:
Naturally, to cover all of these considerations in our first release of the revamped notification system was infeasible. We accepted that as we were designing our new system, we would probably not be able to allow customization along all of these axes. We decided that our system must cover the “medium” and “object scope” axes, and that we should keep the other ones in mind but not compromise our design to achieve them.
Push notifications are implemented differently across the various mobile platforms (iOS, Android, etc) but all of them work under the same principles:
Throughout this process, TribeHR never learns the identity of your device – the notification token is only valid as long as the TribeHR app is installed on your phone. (If you’re interested in more details, and how this scheme protects your privacy, you can check out Apple’s documentation on the subject.)
We wanted users to be able to log out of TribeHR on their phones remotely, so in addition to collecting the notification token, we also collect a few other bits of information – the device name (eg, “Jason’s iPhone”), operating system (iOS or Android), which version of the app is installed, etc. This allows us to list the user’s devices so that they can log out remotely.
When the user logs out, we need to remember to delete that notification token from our list, so that we don’t send push notifications to a phone that’s logged out of TribeHR! This poses a problem when the user logs out of the app on their phone, but aren’t currently connected to the internet. For this reason, we disallow logout on the iOS app if the phone isn’t connected to the internet.
For the time being, we’re giving employees control over which medium they’ll receive notifications. You can’t choose to forego notifications, so you know that your manager will always know about your vacation request.
If you haven’t signed into TribeHR for iOS, you won’t see the “Notifications Preferences” menu item, and all of your notifications will arrive via email. Once you’ve signed into the mobile app, you’ll be able to choose whether to receive notifications by email, push notification, or both.
Tapping on a push notification will bring you directly to the related screen in the iOS app, so that when your subordinate submits a leave request, you can review it right away.
Our previous notification system was less a “system” and more an ad-hoc collection of “and then send an email!” bits whenever we saved a change to a leave request or created a new kudos. Just adding in “and also a push notification” to that workflow was a non-starter for us. The fact that our notifications were sent on such an ad-hoc basis was an instance of technical debt for us – something that was written early in our startup days. We always “love” tackling old bits of code and making them cohesive systems. Or at least, we love the results, even though the process is sometimes painful. We’re really happy with the way we’re sending notifications now.
And while we are absolutely not promising anything along these lines, we are excited that we now have the ability to expand and improve the ways we notify users of important things that are happening in their HR system.
©2018 NetSuite Waterloo. 55 King St. West, Suite 900, Kitchener, ON | NetSuite | TribeHR