Internal PTO Management

While working at LLT, we were struggling to find a clean and simple way to manage PTO requests for our employees. We needed a reliable solution that allowed an employee to log in and view how many PTO days they’ve used or have left, as well as the ability to submit a new PTO request.

Hearing the needs of the company, I found an especially motivating weekend to build out an MVP for this project. I used my go-to framework, Ruby on Rails, and it’s been working like a dream ever since.

As an added bonus, I built in a way for the system to notify you via Slack before sending you an email if the Slack webhook fails. In either case, you’re provided a direct link to get what you need done and out of the way.

All of this runs through our CI / CD system build on top of GitLab, which automatically runs our tests and deploys when they pass. This provides a small layer of abstraction in the development and deployment process, allowing developers to focus on what they do best–writing code.

About a year after its launch, the desire to build out more internal tools grew within the company. So I transitioned the authentication system to the single-sign-on (SSO) provider Auth0, which then requires employees to keep track of a single account rather than an account for each system we build. This transition also makes the creation of new tools much quicker, as we no longer need to worry about authentication and can focus on the problem we’re trying to solve.

One of the challenges was needing to have some sort of approval chain for the PTO requests. As a Team Lead, my team’s requests needed to go directly to me for approval. Once I approve the request, the person in charge of logging those hours into our payroll system then needs to be notified of the approval details.

To solve this, all users are assigned to a team, with each team having a single “team lead” or user with team lead privileges. The team lead is then notified when a request is submitted by one of their teammates and is provided a link to review and approved / deny the request. A nice side-effect of this is each member of that team knows exactly who to go to if they’re having any issues with their PTO.

Another challenge with this build, which didn’t come up until the latter half of the year, is PTO requests that start in one year and end in another. This was a problem because this is when PTO resets within the company, meaning the amount of time someone takes must correlate to the year which that time was taken.

The current solution is a check to see if the request started in one year and ended in another, followed by a little bit of arithmetic to add / remove days where needed. We’re able to keep this calculation quick by leveraging SQL, rather than store / managing fixed values. This also provides more flexibility in rendering the data we deemed valuable to the UI.

Since this project’s inception, I’ve been its sole contributor. This includes design. While I’ve opened it up for internal contributions and announced a desire to have people work on it, from both designers and developers, none have stepped to the plate. It remains the primary mode of submitting and managing PTO within the company at all levels.