A workflow is a standing rule that carries a post from one social account to another inside the same brand. It reacts to what appears on the origin account or releases what the workspace has collected at a rhythm you set, it decides the format from the pair of networks, and it never reacts to what the product itself published.
One rule, two accounts, one brand
A workflow is not a campaign and not a template. It is a rule that lives inside a brand and joins two connected accounts: one the content comes from, and one it goes to. On screen they are two columns, "Post from" and "Post to", and that is the whole structure of a rule.
It could have been a fan out instead, one origin and six destination checkboxes, and at first glance that looks more convenient. It is not. With a single destination the post format falls out of the pair rather than being a matrix you have to understand; the compatibility question is asked and answered about one concrete thing; and the whole rule reads at a glance, which is exactly what you need on the day something comes out wrong. If you want three destinations you write three rules, and each one can be paused, reviewed or deleted without touching the other two.
Accounts live inside a brand, so a rule carries from one account of that brand to another account of the same brand, and never crosses between brands. That holds the same way for an agency with twenty clients, for an in house team with two brands and for a creator with their own: the module is identical and so is the boundary. The screens are on the workflows page.
The two kinds: react or release
The first kind is automatic, and it is defined by what it watches: the origin account. Every time you publish from that network's own app, the rule sees it and prepares the same piece for the destination account. It is not instant, and the interface says so in as many words: each origin account is checked every half hour, so a while can pass between publishing and the piece appearing on the other network.
The second kind releases rather than reacts. You choose which posts to include by date window, which order they go out in, newest first or oldest first, how many you want per day up to five, and up to five two hour slots per weekday, with weekday and weekend groups kept apart and the time zone written next to them. From there the planner places one piece in each slot and does not step outside that rhythm.
It is worth being exact about what the drip releases, because this is where the category tends to promise too much: it distributes what the workspace has collected since you switched the rule on, not your entire back catalogue. The reason is technical and no amount of copywriting fixes it: the file links a network hands over expire within days, so an old post can be listed and can no longer be republished.
Which networks can be the origin, and why the rest cannot
The origin is Instagram, Facebook or a LinkedIn company page. That is not a product preference or a shortlist: the connected accounts were asked for their history and one byte of every media file they returned was requested. Instagram hands over the whole reel video, Facebook hands over the video and LinkedIn hands over the carousel images.
TikTok, YouTube and the Google profile return the post record, the permalink and a thumbnail, and nothing else. That is plenty for analytics, which is what it exists for, and it is not enough to republish: without the file there is nothing to carry anywhere. So those three do not appear in the origin column, and the wizard says it on the disabled tile itself rather than letting you get as far as saving before refusing. It is a fact about how those platforms work today, not a pending checkbox.
The destination column is far wider: almost any network you can connect for publishing can receive, including the three that cannot be an origin. Which is why the most requested direction works end to end, publishing the reel on Instagram and wanting it on TikTok and on Shorts as well. The opposite direction is the one that does not exist, and saying so plainly saves you discovering it with the rule already built. If you are weighing up tools in this category, that difference is worked through in the comparison against tools specialised in repurposing video.
The pair decides the format, not you
When you pick an origin and a content type, a compatibility matrix works out what would happen to that shape of media on every destination network. The answer is one of three verdicts. Clean means nothing structural objects and the destination is offered first. Conditional means it depends on the specific file, by duration, aspect ratio or weight, and it can be picked with the caveat written under the tile. Impossible means that shape never fits there, so the tile cannot be picked at all and gives its reason in one sentence.
| Pair | Verdict | What it means |
|---|---|---|
| Instagram reel to TikTok | Clean | A vertical video fits as it is, so the pair is offered first |
| Instagram reel to a YouTube Short | Conditional | Vertical is right, but that network caps duration lower and you are warned |
| Instagram photo to YouTube | Impossible | That network only has video formats, so an image has nowhere to go |
| Instagram carousel to Pinterest | Conditional | Only one file fits, so the first one would go and you need to know beforehand |
| Facebook video to the Google profile | Impossible | That network does not accept video in its posts |
| Any image to Bluesky | Conditional | The size ceiling is low and most phone photos get recompressed |
| Instagram story to LinkedIn | Conditional | Outside Instagram and Facebook that format does not exist, so it goes out as a normal post |
The check runs three times and all three are needed: when the destination column is drawn, when the rule is saved, because the server does not trust what arrives from the browser, and once more per delivery against the file already downloaded and measured. That third one is the only check that can look at real duration and real aspect ratio, because those figures do not exist until the media is in front of it. That is why a conditional pair can end in a skipped delivery, with its reason, without the rule being misconfigured.
What happens to the caption
Three options and no others: the same text as it was, the same text with a prefix or a suffix you typed, or no text at all. On top of that you can strip mentions, which is the sensible default between different networks because an @handle on one network is a different account on the others and in the worst case somebody unrelated, and you can strip hashtags.
When the destination network's character ceiling is shorter than the origin caption, you choose which you prefer: trim it at the limit, or do not publish to that account. If you choose to trim, the suffix is reserved before counting, so what gets cut is never your sign off, and the preview shows you the cut rather than letting you find it after publishing.
Nothing is written for you. There is no caption generation, no rewriting, no suggestions and no adapting the message per network. The adaptation that does exist is mechanical and fits in one line: trim, put something before, put something after, strip mentions, strip hashtags. Links are left intact. If what you want is a piece genuinely rethought for each channel, that remains a person's work, and the content repurposing guide is about exactly when that is worth doing by hand and when carrying the piece across as it is will do.
Everything in this article happens in one place in GoFeed.
Try it freeWhy it cannot duplicate
This is the part with the least equivalent outside the product, and it is also the real risk in any automation of this kind. The starting semantics are structural rather than a setting somebody can untick by accident: a rule only fires on posts made outside the product. What you compose on the calendar already chose its destinations when you composed it, so replicating it would be duplicating it. A calendar and a rule running at the same time cannot produce the same post twice.
Everything else follows from that. Before anything is created, the post is checked against what the product itself published on that account. Every derived piece records which rule, which post and which account it came from, and the output of one rule can never be the input of another, which closes any cycle even if everything above it fails. Two rules pointing at each other are refused when the second one is created. Underneath, uniqueness constraints in the database do the work instead of checks in code, because two separate processes looking at the same row are a race, and the one that loses the race publishes a duplicate on a client's account.
On top of all that sits a circuit breaker with hourly and daily ceilings, reserving before it plans instead of counting afterwards. If a rule runs away, it is paused and its queue is cancelled rather than flooding the account, and it lands in a state of its own, in an amber nothing else in the module uses, asking to be reviewed before it goes back on.
What you see afterwards
Every delivery is logged, the ones that did not go out included. A rule's history holds the source post, when it was dealt with and the result, and that result distinguishes between planned, published, skipped, failed and cancelled. The difference between skipped and failed is not cosmetic: a network not handing over the file for a post is neither your mistake nor ours, and counting it as a failure would paint any video heavy brand red. So a skip carries its reason in writing and does not count as a failure in the numbers.
The rule list shows origin, destination, how many posts each one has made and its state: active, paused, paused by safety, or finished. Separate from the state sits the automatic publishing switch, which is the honest answer to whether this posts without you looking. With automatic publishing off, every piece the rule prepares lands in the approval queue and waits for somebody to say yes, exactly like any other post on the calendar. In a workspace where the client approves, the approval card also says which account and which date the piece came from, so nobody finds something unannounced in their queue.
And the post that gets created keeps the trail: which rule it came from and which original post, with both links. That is the detail that turns an automation into something reviewable, because when somebody asks in three months why that went out, the answer is on the piece itself rather than in the memory of whoever built the rule.