Augmenting 3rd party employee leave system using the Microsoft Graph API
Posted : Saturday, 11 February 2017 10:34:00
At TruRating we’ve been using the Appogee HR system for leave booking for a while now. It provides a pretty good employee absence management system that allows for approval flows for booking time off, sickness requests and good cross-department absence reporting. It also supports integration with Office365 meaning that an employee can request the absence through Appogee (signing in using O365 creds), their manager will receive a notification or the request. Once the manager approves the request, the employees Office365 calendar is updated with the approved leave event. The same applies for sickness.
So the management view of Appogee looks as follows:
And each employees calendar looks as below meaning colleagues can easily see when people are off directly from within Outlook (or through Office365 in the browser, mobile etc)
This all works great and has been in operation company wide for over a year.
I’m all for WFH (Working From Home) and have been doing it myself on and off for years, it undoubtedly brings benefits but needs to be managed properly to keep the team functioning well. In my current role we allow all of the Development team to take a day a week to work from home. When a team is small a set of simple rules that everyone follows is appropriate such as:
- Days WFH are arranged as far in advance as possible (ideally 1wk with the appreciation this is not always possible)
- Key people should not be WFH (unless exceptional circumstances dictate)
- Any more than 1 day per week WFH is not standard policy and needs to be requested in advance with justification
- Any days WFH must be marked clearly on employees calendar
- Mondays should ideally be avoided as WFH days
- Throughout any WFH days you must be signed into Skype For Business/Slack/etc
However as the team grows this informal framework starts to break down for a number of reasons, people dont stick to it, new starters forget rules, clashes happen where no one is in the office – the last one can really bite when the CEO comes over as their Mac isn’t printing and no one is around to reboot it for them . Essentially an informal set of rules is not a scalable way to manage WFH for a team. I started to look at Appogee to see if we could use it to manage WFH days in the same way as leave and sickness. Appogee natively supports other leave types including non-deducted so we added in the Working From Home as a custom leave type. This works fine except that when the leave is approved, Appogee updates the employees calendar in exactly the same way as leave type. So looking in Outlook there is no way to discern if some is off or working from home:
It should be said that drilling into the calendar event will reveal the leave type:
But its not realistic to expect people to look at their colleagues calendar and click into the event details to see if a person is present of just working from home. I asked Appogee if was possible to augment their system to allow a “subject” override for each leave type to be added. That way, when the employees calendar is updated on approval, if an override is present for a given leave type then that should be used for the meeting subject. This would allow colleagues to know at a glance if the employee in question was actually absent or in fact working from home and therefore available for calls etc. The response was that ‘yes this sounded like a great feature’ but they had a lot of feature requests so I should join the forum and see how popular it might be – with sufficient demand etc. Not what I wanted to hear but I understand the demands on software vendors all too well so started to investigate other options.
In essence all I wanted was as follows: When a particular event is created in Office365 (by Appogee), update that particular event and change the meeting subject – surely not too difficult. As it turns out it was pretty straightforward- although a bit fiddly to set up due to lack of documentation etc. The system I developed consists of two main subsystems, a service to manage subscriptions to each employees calendar which leverages the Microsoft graph API to subscribe to updates on selected users calendars, and a notification service which receives those update notifications and triggers a subsequent update of each matching each calendar event to reset the meeting subject. The process flow is shown below from the point at which the WFH request is approved in Appogee.
The solution makes use of Office365 Notifications and Subscriptions please see this link for more details.
In order to receive event update notifications from the Microsoft Graph an appropriate Subscription must be in place for each user, these subscriptions are managed via the Microsoft Graph API. There is a SQL Azure database in the solution which maintains a list of all users, stores event subscriptions for each user and stores notifications received via the API App for later processing by the WebJob.
There are two custom applications in the solution, an API App hosted in Azure App Service and an Azure WebJob – each is described in detail below. I could have run the custom calendar update inline within the API App (eg as an async task) however during development it quickly became clear that keeping the API as thin as possible made testing the solution easier and much faster to iterate.
Receive HTTP subscription validation requests and respond appropriately – this is a requirement of creating a Graph notification subscription
Receive HTTP update notifications and store for later processing
(The Azure webjob runs every 5 minutes and for each invocation perform the task list below)
Check that each user has a valid subscription, if not then a new subscription is created.
If the user has a valid subscription that is due to expire within the next 10 hours, the subscription is renewed
Process any pending Notifications received via API App and make calendar updates as appropriate
With the WebJob and API App in place, I create a pending WFH request via Appogee, my manager (hopefully) approves it and this causes Appogee to update my calendar. That update in turn triggers a notification to be sent to the API app which is then stored in the SQL Azure database. On the next invocation of the WebJob, the pending notification is loaded, details of the event are retrieved using the Graph API and if the event Subject is “Approved Leave” and the Event body contains “Working From Home” then the event Subject is updated to “Approved WFH” and the status set to “Working Elsewhere”. Finally the notification is marked as processed.
The Microsoft Graph API is pretty easy to use and exposes a load of really great functionality, the act of creating a subscription uses a credential based OAuth token to create the Graph subscription. Updating employee calendars however, requires the use of a certificate based OAuth token to make the calendar update so is much more time consuming to set up – it can all be done through the Azure portal but took me a bit of trial and error to get it set up correctly. I will blog about the setup in a future post.
The solution itself is written in .Net 4.5 and is available on GitHub