Content publishing automation in Make: One video, four channels
How Blam Broadcast uses Make to turn topics into short videos and distribute them across four channels, with a design for safe upload retries.
Last updated
On this page
If Instagram accepts a video and YouTube fails, replaying the entire workflow can create a second Instagram post. Publishing to several channels is straightforward on a good run. The harder part is deciding what to do when only half the run succeeds.
For Blam Broadcast, we built a scheduled Make workflow that takes a topic, generates a short script, makes a narrated and captioned vertical video, writes platform-specific copy and publishes to Instagram, YouTube, Facebook and X. It logs the published links, supports human approval and retries or flags failed uploads.
Key takeaways
- Generate one core asset and track publishing per destination.
- Store post IDs and verify ambiguous failures before retrying.
Separate the video from its destinations
Use one content record for the topic, approved script and rendered file. Keep a separate publishing record for each destination. The caption and public post link belong with the destination; the source video belongs with the content record.
That separation makes editorial revisions easier. If a caption is wrong on one channel, you can correct that caption without paying to render the video again or disturbing the other destinations. If the video itself changes, give the new export its own revision so reviewers know which file they are approving.
Retry the failed destination, not the whole scenario
A rejected file needs a different response from a temporary upload error. Log both against the destination and keep successful post IDs. For an ambiguous timeout, check for a prior post before sending again; the platform may have created it before the connection dropped.
Make offers incomplete executions to retain certain unfinished runs. That feature is disabled by default and does not tell you whether an external service accepted a request. Keep the per-channel publishing record as your own reference.
| Destination result | Next action |
|---|---|
| Post ID confirmed | Save the link and skip on retry |
| Rate limit or temporary failure | Retry that destination with a delay |
| Upload response lost | Check whether a post exists before retrying |
| Invalid video or expired access | Flag for correction or reauthorization |
Put approval where it can prevent rework
Approve the topic and script before rendering if the main risk is factual accuracy. Review the video and final captions before publishing if the main risk is brand fit. Tie approval to a specific revision so later edits cannot silently inherit it.
Before adding a fourth channel, deliberately fail the second. Confirm the other destinations still show their real state, the failed destination can be retried by itself and someone knows where to find the final links.
The takeaway
Track each destination separately so an upload failure can be corrected without creating duplicate public posts.
The cover is an illustration. The example records and test scenarios are illustrative. How we write these guides.