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