Skip to content

icon picker
Deployment guide

A vacation approvals workflow for Coda

🗒️ How does this doc work?

This document can be used to manage vacation requests in a Coda-centric work environment where all members of the team use Coda accounts, according to this workflow:
Share your doc with your whole team with edit permissions, prevent editors from resharing and copying it.

Users fill in a form in .

The request is routed to the people responsible for its assessment according to the department field, as configured in , and emails are sent to all of them.

Approvers can just click on a link inside the email to open a modal view of the request to either approve or reject it and send, at the flick of a button, a notification email to the requester with the outcome and comments, if needed.

Alternatively, requests can also be reviewed and managed by admins more thoroughly in the subpage.

Applicant receives an email with the outcome of the process.


🕰️ Some other moving parts

Every member of the team can check all his/her pending and past requests, as well as some trend charts in .

Every member of the team can check the general vacation calendar of the whole team in .

Some fancy, global stats are also displayed in the public page.


☝️ Please, see further notes and instructions in to understand how the approval policy can be customized.

⚙️ Technical details

This doc uses the . Please, ensure that you provide an appropriate shared Gmail account after making a copy of this document (Insert → Packs → Gmail → Settings → Accounts), if not already set up when duplicating the published doc.
The information contained in some of the pages inside this doc is intended to be private and accessible only to the admin staff. This is rather difficult to attain in Coda (at least for a rookie doc builder like me), as permissions are per doc, not page. To partially overcome this, two Coda’s features you should be aware of have been put to good use:
⚠️ A filter based on the identity of the viewer has been applied to several database views (and also buttons, in its negated form) to hide data from users other than the ones with authority to manage request. By default, any new record in the database will preset to the current user (you!) and the add new department button will be enabled unconditionally as long as there are no registered approvers to make things easier while setting up a new approval workflow.

User().in(ListCombine(Approvers.[People that approve]))
⚠️ , a feature specific of the Team, plan has been set up in a way that non-admins cannot remove the aforementioned filter to access private information. Please, make sure that all pages in your copy of this template are locked and grant unlocking superpowers to admin users only (Locking → Settings → Doc Admins → Specific people.
These are the recommended settings that should be applied in ⚙️ → Settings → Locking:
Use buttons, controls and forms
Read only
Use buttons, controls and forms
Read only
Use buttons, controls and forms , Change table values
Use buttons, controls and forms , Change table values
💡 These locking settings do not allow requesters to change the details of a previous request or even cancel (delete) it. If you don’t feel comfortable with this, simply add Change table values in the lock applied to to allow further edits to previous requests, but bear that this will also allow requesters to modify outcome notes, which is rather inappropriate. Last edited and approval / reject timestamps for each record will always be displayed to minimize misunderstandings, though.

⚠️ Known issues and limitations

In some rare circumstances, approvers cannot edit the Outcome notes field when opening the modal form from the notificacion email they receive when a new request is sent. Not sure if this is a bug (only happened once!) or I am missing something 🤔.
All users can view request and approval comments of any requests displayed inside the calendar when hovering over it. Couldn’t find a way to prevent this, if you feel this is not appropriate, make this calendar view available only to approvers by applying the user filter described in the technical details section.
Currently there is no provision for requesters to cancel requests or modify their details after sending. A lot of room for improvement here, even though a proper workaround seems a little bit convoluted to me.
A lot of the issues and difficulties I encountered when building this doc sprung from the fact that it needs to be shared with edit permissions with people that are only expected to send requests. A public (embedded) form for requests and keeping the doc as view-only for regular users would have probably made things considerably easier, but I stubbornly insisted on these users being able to interact with the filter controls in (edit access needed!) and intended to explore the building possibilities that Coda offered to manage this use-case. I wonder why interacting with controls demands edit access 🙃, oh, Coda 😢, why?
...and many. many more things, for sure, I’ve not had the time and/or experience to detect & iron out.

Any suggestions or advice for a better solution will be very welcome!

🙌 Credits

This doc has been built as my capstone project for the Q2 2022 , a truly great program to learn everything Coda fast! I’d like to thank especially
@Maria Marquis
for the great support throughout these five weeks (and for explaining complex things in the 🆒est and most enthusiastic way possible).
You can reach out to me at pfelipm (at) or 🐦 for questions, comments or whatever.

Make a copy of this doc
Not logged-in? →
Sign up/in
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
) instead.