I’ve tried searching high and low throughout the community forums and asking ChatGPT for advice but have hit a brick wall.
I’d love to know if anyone has recommendations on how to set a page status (e.g. ‘Draft’ ‘Approved’) and also a ‘Date of next review’ and ‘Who’ needs to perform the review? (effectively custom header attributes to a page)
It would be great to then be able to see across pages/workspaces and identify which pages required revision. In our industry (Childcare) all operational documents, policies, processes require revision and review regularly.
Welcome to the community! I hope you will find your time here beneficial.
My recommendation would be to make all the pages canvas columns of a table, and then you can use as many columns in the table to manage the statuses of the information. If needed, a page specific version history and audit trail also becomes a lot easier.
I tried this, but the resultant user-experience isn’t ideal. It means that users now need to navigate to pages via a table vs. the side menu bar. It doesn’t appear that I can do a ‘linked page’ to a ‘canvas’ item.
The nice thing is that with Coda you can have your cake AND eat it.
The below image is of the row including the content in the canvas column. As you can see, there is various pieces of meta data about the information (policy in your case) in the canvas column.
But, using a formula on a blank page, you can then show only the content/ policy on a page, which page is listed in the left hand pane. Following this approach, rather than educating the users, has one drawback - from November onwards, only makers in your pricing plan can create new pages.
Thank you @Piet_Strydom - much appreciated. Will experiment with it and see if the team like it.
I’m a little hesitant it will be readily understood by the wider workforce in an easy to use manner… but is a good work around for now.
I wish they had this as an inbuilt feature to do custom headers!
A further variation on the theme:
I like to keep track using an archive column of the regular updates. (The example below is very informal, the button moves the previous update to the archive, deletes the old entry, and prep the input box with the date and person making the new update. One could build a formal version management system using the same technique.
i built such version management system for a client in the clinical research business.
i also added an extra twist to make the document ‘tamper-proof’ (or at least ‘tamper-resistant’)
we used the ToHtml() function to save a text-only version of the page, and then did another snap-shot when the page was to be archived - and compared the two. this would catch any instances where people managed to edit things without going through the formal process.
its probably an overkill for most cases. but when you are audited by the FDA and drug licenses are at risk - you cant be too careful.
