TribeHR Notifications

TribeHR Notifications

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?

Design

Preferences

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.

Axes of Control

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:

  • Medium – how should I receive notifications? Via email? Mobile?
  • Object scope – about what should I receive notifications? What events do I want to be notified about? Kudos received? Leave request submitted? Goal completed?
  • Context scope – about whom should I receive notifications? Should I receive notifications about new kudos given to other members of my team? Only if I receive kudos? My direct reports?
  • Schedule – when / how often should I receive notifications? Immediately as they occur? As a daily digest?
  • Level of detail / content – what information should be included in notifications? For a long news story, for instance, should it include the entire story or just the title? How should this change across media? For instance, push notifications appear quite small on your phone and don’t allow very much content to be shown.
  • Fallback medium – If I fail to receive a notification on my preferred medium, how should the notification be re-routed? Should I receive an email if my preference is to receive only push notifications, but I’ve logged out of the TribeHR app on my phone?
  • Fallback person – Who should receive notifications in my stead, if a notification fails to be delivered to me, or because of some other situation (maybe I’m on vacation)?

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.

Keeping Track of Mobile Devices

Push notifications are implemented differently across the various mobile platforms (iOS, Android, etc) but all of them work under the same principles:

  1. The app prompts the user – would you like to receive push notifications?
  2. If the user allows it, the phone contacts a server owned by Apple (for iOS) or Google (for Android). This server generates a notification token and sends it back to the phone. Apple keeps track of which tokens belong to which iOS devices, and so on.
  3. The phone sends the notification token to TribeHR. We add this notification token to a list of tokens that belongs to the currently logged-in user.
  4. When we need to send a push notification to an iOS device (for example), we contact Apple’s server and say “send this push notification to the device associated with notification token XYZ”

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.)

Logging Out

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.

Our Solution

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.

Ping! You’ve received kudos.

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.


comments powered by Disqus