A print publication and its website can easily become two separate editorial jobs. Once the layout is complete, the same articles, images, links, cover and issue details often have to be rebuilt for the web. Social posts then create a third version of the work, with another schedule and another set of statuses to manage.
I designed a connected publishing workflow that starts with the approved print files and carries the content through to structured website articles, a social media calendar and automatic Facebook publishing after human approval.
The source material
The workflow begins with the finished production output:
- the final print PDF
- a web-optimised PDF for readers to download
- an IDML export from Adobe InDesign
- the original image folders used during layout
The PDF and IDML have different jobs. The PDF provides the visible article text and page layout. IDML preserves links to the original image files, which are otherwise difficult to recover reliably from the flattened publication.
If the IDML export is missing, the workflow stops and requests it. It does not guess which source assets belong to an article.
From InDesign to website articles
For each issue, the system follows a repeatable sequence:
- Extract the text from the final PDF and identify article headings, boundaries and order.
- Unpack the IDML file and trace the source images linked from each part of the layout.
- Render the finished pages and visually confirm which images are actually placed with each article.
- Separate editorial photography and organisation logos from print adverts and unused linked assets.
- Convert approved imagery to web-efficient WebP files and create accessible alternative text.
- Create one structured MDX entry per article for the Astro website, with the correct issue, order, imagery and organisation relationship.
- Generate the issue cover, add the downloadable web PDF and update the site’s issue record.
- Preview the issue and representative articles before the repository change enters the deployment pipeline.
The visual check matters because an InDesign file can retain links to assets that are no longer visible in the finished layout. A filename appearing in IDML is evidence that the document knows about the file, not proof that readers can see it.
Once approved content is pushed to the main branch, the website rebuilds and deploys through GitHub and Cloudflare. The published article URLs are checked before any social rows are created.
Building the social media calendar
After the web edition is verified, the workflow prepares one pending Notion calendar entry for each eligible article. Every entry contains:
- the article title and production URL
- draft post copy based on the verified article
- an assigned weekday publishing date
- an exact organisation reference where one is available
- a genuine article image when the source material provides one
- an explicit workflow status
The complete date plan is built before any rows are written. Ordinary articles are spread through the issue period, while time-sensitive event articles are scheduled before their event date. The workflow does not backdate an event post or quietly turn a past event into current promotion.
AI assists with concise first-draft social copy. Every name, date, time, venue, link and organisation reference is checked against the source article before the draft is used. An inaccurate result receives one bounded corrective attempt, then stops for manual wording rather than inventing facts.
Images follow similarly strict rules. The calendar uses approved article photography or a defined social asset. It does not substitute a logo, advert, unrelated issue cover or automatically generated fallback when genuine imagery is unavailable. Text-only Facebook posts remain valid.
Creating the calendar does not approve anything. New rows remain pending until they have been reviewed.
Automatic posting after approval
A scheduled Node.js publisher checks the calendar for an approved post that is due. It publishes at most one item per day, using the approved copy, article link, organisation reference and optional image.
The publishing route is deliberately narrow. It can send this content only to the intended Facebook destination, not to other client pages or social platforms.
After Facebook accepts the post and returns its identifier, the publisher:
- marks the Notion entry as posted
- stores an idempotency receipt for safe recovery
- emails a completion notice with the Notion entry and Facebook post links
A stored idempotency receipt protects retries. If Facebook succeeds but a later status update or notification fails, the workflow can complete the remaining steps without posting the same article again.
Technology used
- Adobe InDesign, IDML and PDF for the approved print layout, article content and traceable source assets.
- Astro and MDX for structured issue and article content.
- Node.js and Sharp for deterministic processing, image optimisation and scheduled publishing.
- Notion and its API for the editorial calendar, approval status and publishing record.
- GitHub and Cloudflare Workers for the website build and deployment path.
- A bounded social publishing service and the Facebook API for approved posts.
- A private AI model service for first-draft social copy, with factual verification before use.
Safeguards and failure handling
The useful engineering sits as much in the stopping rules as in the happy path:
- Missing IDML or source imagery stops the affected work instead of triggering a guess.
- Visible PDF pages are the authority for image placement, not the raw IDML link list.
- Existing calendar rows are matched by issue and article URL to prevent duplicates.
- Event posts require a valid date before the event and are never silently backdated.
- Unverified AI copy is not written into the live calendar.
- Missing editorial imagery produces a text-only post, not an invented substitute.
- Only approved and due rows can reach Facebook.
- Idempotency state prevents a retry from creating a duplicate public post.
- The resulting website pages and calendar state are checked directly, while Facebook acceptance and the returned post link are recorded.
My role and the AI contribution
I designed the end-to-end workflow, defined the source files and content model, set the image and scheduling rules, connected the website, calendar and publisher, and decided where review was required. I also tested the workflow’s real outputs and state transitions.
AI assisted with implementation and social copy preparation. Deterministic code controls validation, dates, status transitions, platform routing and posting. I remain accountable for the editorial rules, permissions, approval boundaries and published result.
What this project demonstrates
This is a live integration across creative production, content modelling, website deployment, editorial planning and social publishing. It turns one approved print issue into reusable digital content without treating automation as permission to bypass editorial judgement.
The defensible outcome is a single controlled workflow connecting design sign-off, website articles, the social calendar and the final Facebook post. A measured time-saving figure has not yet been published, so no productivity percentage is claimed.
Current limits
This is approval-gated automation, not a completely unattended publishing system. The IDML export, visual article checks and social approval remain human responsibilities. Automatic social publishing currently covers Facebook rather than every social platform. The publisher confirms that Facebook accepted the post and returned a reference, but it does not read the final rendered post content back from Facebook. Full rendered-content verification remains a manual check.
What is deliberately not published
This account excludes the publication and client name, production files, article content, contact details, internal paths, database identifiers, page identifiers, credentials, private endpoints and exact security configuration.