Im more curious than anything. Why not create a new document?
The old notes could be referenced and the new notes could still be scheduled for release?
I understand the many links causing issues. You could create a new KB category category like Archived and move anything older than a year into this location.
Following - we have this same issue - 20+ products and many articles.
@mitchell.gordon in our case, we do not want to create another article and archive the old. So many of our customers bookmark our articles and would then report that it’s out of date without looking for the updated one. It’s a lot to manage with our large number of products. We do always create new articles for our releases though.
@jlavorini thanks for that use case! I haven’t run into an org that does something like this before.
I’ve always had users subscribe to an area and post a new article. Interesting to learn more about how people run their platforms.
Following - we have this same issue - 20+ products and many articles.
@mitchell.gordon in our case, we do not want to create another article and archive the old. So many of our customers bookmark our articles and would then report that it’s out of date without looking for the updated one. It’s a lot to manage with our large number of products. We do always create new articles for our releases though.
Exactly the same! We also have article links that exist in other articles and creating a whole new article for an update would break all those links. We also have article links in product and in Pendo. Sometimes the update is small (adding a note, switching out a screenshot) and sometimes it’s larger. And for new features, of course, we create new articles and release notes are always new.
I’ve never tried this, but it sounds like it might work.
- Publish original article to the appropriate category
- Draft the updated version, schedule when ready. Have this set to publish to a private category only staff can access.
- Automate updating the copy from version 2 on the public post of version 1.
Here’s the automation:
- Webhook for new post: should give you the html code for v2
- a way to match v2 with v1 (you could just put the articleId in the title of v2 if you don’t need to update the title, then the webhook would provide the articleId to update as part of the event payload)
- API operation to update v1 using the body copy (and code) from v2
- Optional steps to delete v2 and/or comment on v1 to announce the update, etc
in theory, even images will work. They will exist on your community server as files and their image reference url will be in the code. When it gets updated on v1, they should render. (Though if you do the optional delete step, check with gainsight on whether the images will expire from the deleted post at some point.)
you don’t need to worry about changing urls, because the v1 url is still being used, but the copy will now be updated.
you probably want at least a manual step to check the end result at least in early stages. And I’d recommend an error handling step or alert as part of the automation as well.
This sounds interesting, @DannyPancratz I will give it a try and let you know how it goes.
Thanks!