Vacation approvals

Your requests

Staff on vacation

Team stats

Admin-only area

Explore

Deployment guide

A vacation approvals workflow for Coda

Pablo Felip

🗒️ 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

Your requests⁠

⁠

The request is routed to the people responsible for its assessment according to the department field, as configured in

Data tables & setup⁠

→

Approvers⁠

, 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

Requests management⁠

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

Your requests⁠

⁠

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

Staff on vacation⁠

⁠

Some fancy, global stats are also displayed in the public

Team stats⁠

page.

⁠

☝️ Please, see further notes and instructions in

Data tables & setup⁠

to understand how the approval policy can be customized.

⚙️ Technical details

This doc uses the

Gmail Coda Pack⁠

. 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

Approvers⁠

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

⁠

⚠️

Document locking⁠

, 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:

⁠

Your requests⁠

⁠

Use buttons, controls and forms

⁠

Staff on vacation⁠

⁠

Read only

⁠

Team stats⁠

⁠

Use buttons, controls and forms

⁠

Admin-only area⁠

⁠

Read only

⁠

Requests management⁠

⁠

Use buttons, controls and forms , Change table values

⁠

Data tables & setup⁠

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

Your requests⁠

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

Staff on vacation⁠

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

Team stats⁠

(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!