Photo by Jez Timms on Unsplash

Sharing sensitive PTO data

Using a cross doc and hoping for the best

Christiaan Huizer

--

The PTO request process begins with a form completed by either the employee or HR. The form encompasses sick leave and holidays, including requests and cancellations for past, present, and future dates. Once submitted, an automation triggers two buttons. The first initiates a process that calculates the hours to be added or deducted from the PTO balance, while the second determines the next working day. Both processes take into account various factors like evolving work schedules, holidays, and previous requests or cancellations.

The outcome of these processes is a summary that correlates the newly entered data with the existing data, providing a comprehensive overview.

This summary resides within the PTO doc, an action doc located in the HR folder, accessible exclusively by HR staff. The challenge lies in securely sharing this data with employees and their direct supervisors (N+1) to ensure everyone stays informed.

Teams like marketing & communication, HR, and operations maintain hubs — documents where they share procedures and information pertinent to their respective areas. For instance, the operations hub provides guidance on handling devices, updates, and repairs. Similarly, HR has a team hub encompassing upcoming holidays, an organizational chart, procedures, and a dedicated page informing employees about their PTO requests.

Alternative methods to link an action doc to a hub

To connect the PTO action doc to the HR Hub, I’m utilizing the cross-doc pack I previously discussed. The recent improvements make it simpler to display data in the target doc (the HR Hub), but the procedure still carries some risk. Before sharing my cross-doc setup, let me touch on three other options.

Firstly, an alternative could be using Slack, but that’s not viable as it leads to excessive and undesirable interaction. This is an often-overlooked drawback of the tool. While I was an early adopter, I abandoned it due to its tendency to encourage constant engagement.

Secondly, I could utilize my webhook pack. It’s fast, error-free, and requires crafting the final message directly within the HR Hub. This is because all formatting is lost during the process, leaving you with only plain text or images. The downside of this approach is that to share summaries across multiple documents, you need to recreate and style them individually in each one — not something I prefer. However, apart from that, the webhook pack is reliable. I use it, for instance, to transmit sensitive personal information that needs to be delivered instantly, and the webhook excels in that scenario.

Ideally, I would have preferred a variation of the current sync page functionality. A sync page that displays only the rows relevant to the user viewing it would be perfect. Technically, this is challenging as Coda would need to identify the user in the container doc and pass that information to the target doc to generate the appropriate view. I hope we’ll have something like this one day.

Failing that, a central notification center that doesn’t directly link back to the source table would be a fantastic alternative. This would unlock much more powerful usage of Coda. In our workspace, such a notification center could operate across all or a selected subset of our docs.

The webhook pack creates extra work, which we’d like to avoid. The smart user-sensitive sync page doesn’t exist yet, nor does the notification center. This leaves us with the remaining option: cross-docs.

The cross doc set up

It all starts in the source doc. A message table links the outcome of the two main actions resulting in a message like below.

example of the message

This message is — due to the cross doc pack — shown in the HR Hub. An automation is put in place to alert the employee (Hélène) in this scenario and her supervisor. This alert sends a notification based on the user names of both which are part of the cross doc table. The supervisor is created in the source doc, in our scenario the PTO doc.

To prevent everyone from seeing all the information, we’ve added a filter based on the employee’s and supervisor’s names, along with the next working date. Once that date has passed, the messages will disappear.

Sometimes HR needs to manually add past vacation or sick days for an employee. These changes will be visible in the HR Hub for the next two days. We use a special formula in the PTO document to handle these updates.

booking for the past

To summarize, we have the following options for displaying the message:

  • Until the next working date: This is the standard approach.
  • Today and tomorrow only: We use this for past bookings.
  • Never: This is for instances of double bookings or double cancellations.

The automation

Whenever a new request comes in, it triggers a notification to both the employee and their supervisor. The filter is personalized, so when they click the notification (in Coda or via email), they’ll see the full details in the table.

the automation that handles the notifications

Open ends

We have two documents: the PTO document and the HR Hub. They work together smoothly for the most part, but the lag between them can be annoying. Our biggest challenge is that we still don’t have a good way to handle sensitive information. Late last year, I wrote about how document leaks and inconsistencies can negatively impact the product.

The ideal solution, in my view, is a synced document that listens to the user in the main document and provides a filtered view based on their specific permissions.

In the short term, this might be beyond the Coda team’s capabilities. So, I propose a suggestion: What if we could modify the search bar settings to allow users to choose which pages are included in their search results? It seems like the easiest way to do this would be to leverage the existing page settings.

Until a more robust solution is implemented, we rely on employees to respect the confidentiality of PTO information and refrain from seeking it out unnecessarily.

I hope this article was informative and helpful. Did it help you to solve a problem you unlike would have solved other ways? What about a donation?

My name is Christiaan, and I regularly blog about Coda. While this article is free, my professional services (including consultations) are not, but I’m always happy to chat and explore potential solutions. You can find my free contributions in the Coda Community and on X. The Coda Community is a fantastic resource for free insights, especially when you share a sample doc.

--

--

Christiaan Huizer
Christiaan Huizer

Written by Christiaan Huizer

I write about how to Coda . You find blogs for beginners and experienced makers. I publish about 1 / week. Welcome!