Every once in a while you get a request that intrigues you. This time, a client asked if we could create a flow for the automatic publication of an asset. The client wants to put in a new version of an asset ready for publication but only be actually available once the scheduled date has been hit.
Unfortunately, the Content Hub doesn't support scheduling tasks or scripts within the Content Hub at this moment. I hope this will be added to the features in the future. But for now, we need an outside process to trigger an internal script. But more on this later, let us focus on the process.
In the schema below you can find the process steps that we need to do. We first need an Asset in the Approved state, also known as the Original asset. Based on this Asset we will create a Draft version. This is actually a new asset in relation to its parent, the Original asset. All values, like taxonomies and such, are copied over by default. You can manipulate which fields and/or relations are copied over if you need to. Read the earlier blog post about this topic. It will tell you exactly how to do that.
Once the Draft has been created, we can set a publication date* and change any metadata if needed. From there on, we can Submit the asset for review. Once the Asset has been set to the UnderReview state and the publication date is set, we can leave the asset.
* publication date -> custom field that is used for the business rules to see if the Asset may be published.
On the righthand side is the automatic process. This process will need to live outside of the Content Hub. It could run inside an Azure Function or an AWS Lambda. When the timer has passed it will remotely call the Publishing scripting within the Content Hub. That script will be responsible for publishing all draft assets that meet the business rules that apply. For each asset that is found, it will trigger the approval process. During this process, it will merge the Draft and the Original asset together and therefore making the Draft asset not publically available.
Remark: In this case, we have chosen to put in the actual logic within the Content Hub itself, via the Scripts. You could also argue that you want to store it with the trigger. Our recommendation is to keep the logic as close to the Content Hub as possible. This will make transferring the logic into a scheduled task within the Content Hub a whole lot easier when that feature comes available in the future.
Until next time!