Sync knowledge articles between instances

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-21-2024 08:06 AM
Hello everyone, I have a problem to solve, knowledge articles are currently created directly in production.
Necessity: Whenever an article is approved and published in production, that same article must be created in the DEV environment with the same sys_id, attachments and status.
Is there an OOB way to do this synchronization?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-21-2024 08:35 AM
There isn't an OOB solution for this, unless you include Clones which cover much more than just knowledge.
Flow Designer + Integration Hub can be used to trigger the process of integrating with the lower environment, and then creating the needed records in the relevant table, however you may have issues with synchronising sysIds
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-21-2024 09:02 AM
Why is it important to preserve the sys_id?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-21-2024 11:05 AM
In case of changes between records, sys_id guarantees that the same records are changed in relation to the parent record "knowledge article" and also the records created from it "attachments"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-21-2024 01:18 PM
If Flow Designer has a step to set the guid (sys_id) on a target record (sorry, I have no idea), I would try that: Check for a record matching the sys_id, optionally create one, and set the content.
You would also have to check for the addition/deletion of attachments on your kb, and set up another flow to handle that.
The flow(s), or more likely whatever is triggering them, would have to know to skip all this if the update happened in the lower environment.
If FD does not support setting the guid you could set up a scripted REST endpoint in the lower environment and, having checked for the existence of a record having the prod sys_id (a GET call), create one (POST), parse the response for the sys_id, and then make another call to update that record with a new sys_id (a PUT probably, where the endpoint calls GlideRecord.setNewGuidValue() on the record created through the first POST), or push the updated content.
Try calling that operation from FD.
You could probably keep all the attachment-handling in FD.
You could implement the logic in a Flow and leave the code details in your endpoints.
So, no, there's nothing OOB AFAIK.