Software product
Every release ships with all of its content, or none of it ships
One orchestrator, four child workflows, and a categorisation step that routes six kinds of attachment down six different paths before any of them becomes publishable.
Client: Elementor
System flow and narrative
Attached as: Confluence page. Review outcome: Approved. Path: Release status change, then Issue pulled in full, then Attachment categorised, then Page fetched, then Merged into one object, then Four webhooks fired, then Internal brief, then Help centre article, then Quiz questions, then Slide deck, then Human approval, then Publication run, then Newsletter posted, then Article published, then Quiz form created, then Deck assembled, then Checklist closed.
Every release ships with all of its content, or none of it ships: system flow
Edges: live is a thicker, full-opacity, travelling dashed line; not taken is a thinner, dimmed, solid line. Nodes: live is a thicker, full-opacity outline; not taken is a thinner, dimmed outline. Color is never the only signal.
01
A status change, not a schedule
Every product release required coordinating content across internal briefs, help centre articles, quizzes and slide decks, by hand, across five separate platforms. The replacement is a 123-node system: one orchestrator and four child workflows covering the whole lifecycle. It starts when a release issue changes status in Jira, which means the content pipeline runs on the same signal the engineering team already uses rather than on a calendar that drifts away from the real release date.
02
Six kinds of attachment, six ways in
The orchestrator pulls the full issue and a categorisation step sorts everything attached to it. PDFs, DOCX and TXT files, Confluence pages, Google Docs, GitHub pages and the raw description text each go down their own branch. A PDF is text-extracted. A Confluence page is fetched as HTML, converted to Markdown, then stripped of interface noise that would otherwise read as content. A Google Doc comes through the Docs API. A GitHub page is converted to clean Markdown by an agent. The board switches between four of these; the categoriser handles all of them.
03
One object, whatever came in
Every branch merges back into a single normalised object. This is the step that makes the rest of the system possible: the four child workflows downstream never have to know whether a given release brief arrived as a PDF, a wiki page or a paragraph typed into a Jira description. Handling heterogeneity once, at the boundary, is what keeps four separate content pipelines from each growing their own copy of the same conversion logic.
04
Four children, fired in sequence
From the normalised object, four webhooks fire in controlled sequence, each starting a child workflow, with deliberate waits between them so the downstream services are never flooded. The four cover the internal brief and its newsletter, the help centre article, the quiz, and the slide deck. They run as separate workflows rather than one long one because each has a different destination system and a different reviewer.
05
Every child ends at a person
This is the branch that matters most. No child workflow publishes anything on its own. The internal brief goes to Airtable for approval, the help centre article is drafted into a Google Doc for review, quiz questions land in Airtable first, and slide images are assembled only once approved. Until a human approves, the work sits in the tool that person already uses and nothing downstream runs at all. An AI system that writes publication-ready content and then waits is a different kind of system from one that writes and posts.
06
What approval actually releases
On approval each child completes its own chain. A second agent writes the newsletter from the approved brief and posts it to Slack. The help centre article is converted to publication-ready HTML, pushed to WordPress, and then the Confluence checklist is updated with the live URL, which is the step that closes the loop and leaves the release record pointing at the published page. Quiz questions are deduplicated, sorted and inserted into a new Google Form. Slide images are pulled from Drive and sorted to guarantee ordering before the deck is assembled.
The branch logic, as a table.
| Condition | Then | Why |
|---|---|---|
| on a status change only, never a schedule | Issue pulled in full | |
| Attached as is PDF | Text extracted | |
| Attached as is Confluence page | Page fetched | |
| Attached as is Google Doc | Document fetched | |
| Attached as is GitHub page | Page converted | |
| Attached as is PDF | Merged into one object | text extracted from the file |
| Attached as is Confluence page | Merged into one object | HTML to Markdown, interface noise stripped |
| Attached as is Google Doc | Merged into one object | through the Docs API |
| Attached as is GitHub page | Merged into one object | converted to clean Markdown by an agent |
| Review outcome is Approved | Publication run | |
| Review outcome is Changes requested | Held for revision | nothing downstream runs |
| Review outcome is Approved | Newsletter posted | a second agent writes the newsletter first |
| Review outcome is Approved | Article published | converted to publication-ready HTML |
| Review outcome is Approved | Quiz form created | deduplicated and sorted first |
| Review outcome is Approved | Deck assembled | images sorted to guarantee ordering |
| Review outcome is Approved | Checklist closed | checklist updated with the live URL |
The stack.
| Layer | Tools |
|---|---|
| Issue tracking | Jira |
| Wiki and documents | Confluence, Google Docs |
| Orchestration | n8n |
| AI agents | LLM content agents |
| Review and configuration | Airtable |
| Publishing | WordPress |
| Forms | Google Forms |
| Decks | Google Slides, Google Drive |
| Messaging | Slack |
Safeguards.
- System prompts live in Airtable rather than inside the workflow, so tone and style are tuned without touching the build.
- Rate-limit buffers sit at every external boundary, and the four child webhooks fire with waits between them so no downstream service is flooded.
- Categorisation defaults gracefully on missing fields instead of breaking the run.
- Known-problematic Confluence pages are filtered out before they enter the pipeline.
- Every child workflow terminates at a human approval, so nothing reaches a public surface without a person releasing it.
Before and after.
- Release content coordination
- Before: Assembled by hand across five platforms, every releaseAfter: One orchestrator and four child workflows, triggered by a status change
- Source handling
- Before: Each attachment type opened and converted manuallyAfter: Each type routed down its own branch and merged into one normalised object
- Editorial control
- Before: Review happened wherever the document happened to liveAfter: A named approval gate closes every child workflow before anything publishes
- Prompt tuning
- Before: Changing tone meant editing the workflow itselfAfter: Prompts live in Airtable and are changed without a deploy
- Help centre publication
- Before: Draft, convert, publish, then update the checklist by handAfter: Approval converts, publishes, and writes the live URL back to the checklist
This is one delivered system, published in full. See how we build AI automation
Want this on your own stack? See our n8n automation agency page.
Start a conversation
Tell us what you’re building.
Share the essentials and we’ll reply within 4 hours with a real next step, not an auto-responder.
What happens next
- We reply within 4 hours, from a real person, not an auto-responder.
- A short scoping call to understand the goal, constraints, and timeline.
- A fixed-scope discovery sprint: a working prototype and a written estimate.
- info@irenictech.com
- Office
- Austin, TX, United States
- Hours
- Mon–Fri · Async + scheduled calls