Editorial Workflow Software: Getting a Story From Commission to Print, Web and Syndication Without Losing the Version

Why editorial workflow breaks at exactly the wrong moment

A features editor commissions a 2,400 word piece for the November issue and for the site. She agrees a fee over email. The writer files into Google Docs. A sub works on it in the doc, then it is pasted into the CMS for web and separately flowed into InDesign for print. Legal wants a read before publication because there is a named individual in paragraph nine. The picture desk licences an image from an agency, and the licence covers web and print in the UK for 12 months, which nobody records anywhere a machine can read. Then the interview subject's publicist confirms the embargo lifts at 00:01 Thursday.

Thursday morning the piece is live on the site at 00:01 as agreed. It is also in the newsletter that was scheduled for Wednesday evening by a different team working from an earlier date, and a syndication partner ran it Wednesday afternoon because the feed does not carry an embargo field. The publicist calls. Access to that talent is gone for a year.

Every part of that story is ordinary. The commission fee is not connected to the budget, so the editor finds out in month nine that features is 18 per cent over. The web version and the print version diverged after the legal read and only one got the correction. The image licence expiry is in a spreadsheet the picture editor keeps. Across publisher projects we have delivered, the recurring cost is 6 to 10 hours a week per desk chasing status, one or two rights or embargo incidents a year that cost real money or real access, and a print week that depends on two or three people knowing where everything is.

Problem 1: the story is not a file, and treating it as one is the root cause

Most publishing stacks model a story as an article record in a CMS. What editorial actually manages is a commission: a brief, a commissioned writer at an agreed fee, a target channel or channels, a word count, a deadline, a set of assets, a legal status, an embargo, and a publication slot in more than one place. The article file is one artefact of that commission, and print produces a different artefact from digital.

WoodWing Studio is genuinely excellent at the artefact problem for magazines. If your pain is InDesign round tripping, layout status and getting copy into pages, it does that better than almost anything you would build. What it does not model is the commission upstream of the layout, with a fee, a contributor contract and a budget line. Arc XP is the mirror image: strong digital first publishing at scale, and no answer at all for a printed page. Censhare can model almost anything, which is the problem, because it is a framework and implementations run long. Naviga bundles editorial with advertising and circulation, which suits a regional newspaper group and couples you to their stack if it does not.

What a custom build does: the commission is the primary object and everything else hangs off it. One record holds the brief, the contributor and fee, every channel the piece is destined for, and the status of each channel separately. A piece can be legally cleared for web and still blocked for print because the print version has a caption the lawyer has not seen. That single distinction is what removes most version confusion.

Problem 2: an embargo has to be a rule, not a note in a Slack thread

Embargoes fail because they live as human agreements while publication is automated. The newsletter tool has its own schedule. The syndication feed pushes on ingest. The app pulls from a different endpoint with its own cache. Each of those is a separate system with a separate person, and the embargo exists in none of them.

What a custom build does: embargo becomes a property of the content with a timestamp and a timezone, and every publishing surface reads it before it emits. The newsletter builder refuses to include an embargoed item scheduled before the lift time. The syndication feed either withholds the item or, where the partner supports it, carries the embargo field and the partner honours it contractually. The app cache respects the same clock. Then when a publicist moves an embargo by six hours, you change one value and every surface follows, instead of four people trying to remember what they scheduled.

The same mechanism carries takedowns and corrections, which is the other side of the risk. If a legal complaint requires a paragraph removed, you need to know every surface the piece reached, including the syndication partners who took it, and you need that list in minutes. A build that tracks distribution as an event log gives you it. A CMS that publishes and forgets does not.

Problem 3: image rights expire and nothing tells you

A picture desk licences from agencies, commissions photographers, uses handout images with usage restrictions, and takes reader submissions. Each of those carries a scope: which channels, which territories, how long, whether the archive counts, whether social counts. The licence terms arrive as a PDF or as text in an email. The usage lives in the CMS. Nothing joins them.

Then a rights holder's monitoring service finds a 2019 gallery still live with an image whose licence ran 12 months, and sends an invoice. Every publisher we have worked with has a version of this story.

What a custom build does: the image is an asset record with structured licence terms including permitted channels, territory and expiry, and every use is recorded against it. Before publication the system checks that the intended channel is inside the licence scope, and blocks a print use of a web only licence at the point of layout rather than after press. Expiring licences produce a work queue in advance, so somebody either renews, replaces or unpublishes deliberately. This is one of the few features where the payback is directly measurable against invoices you stop receiving.

Problem 4: print and digital run on two clocks and one newsroom

Print has a fixed press deadline and a pagination that must balance. Digital has no deadline and infinite space. The same journalists serve both, and the systems that support them share nothing, so the status of a piece is genuinely different depending on who you ask. The features editor thinks it is done because it is live. Production knows it is not, because the print version needs cutting to 1,900 words to fit the page and the cut version has not been legalled.

What a custom build does: one piece, multiple channel renditions, each with its own state machine. The web rendition can be live while the print rendition is still in sub. Cuts and changes made for print are visible against the web version so a correction applied in one place raises a flag on the other. Where InDesign is in the mix, the practical integration is IDML and InCopy assignments rather than trying to replace the layout tool, because your production team is fast in InDesign and a custom pagination tool would be a downgrade. Build around the layout tool, not over it.

Problem 5: the archive is the migration, and the migration is the project

Publishers underestimate this every time. Twenty years of content across two or three CMS generations, with dead shortcodes, inline HTML from a 2009 editor, images on a decommissioned server, URLs that carry search authority you cannot afford to break, and a taxonomy that was reorganised twice. Moving that is not a data load, it is a normalisation project with editorial judgement in it.

What a custom build does: treat the migration as its own workstream with its own budget line from day one. Content gets parsed into a clean structured model, redirects are generated and tested against real traffic logs so the pages that actually earn are protected, and orphaned assets get found before launch rather than by a reader. We plan for the archive to be migrated in tranches by traffic value, most valuable first, running in parallel with the new stack rather than as a big bang. Any publisher plan that shows migration as a two week task at the end is a plan that slips.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape for publishers is this. A first release covering commissioning with budget and contributor fees, the multi channel status model, embargo handling and digital publishing for one brand runs $90,000 to $180,000 and ships in 14 to 20 weeks. A full programme adding print pagination integration, rights managed asset handling, syndication and partner distribution, multi brand support and archive migration runs $250,000 to $700,000 phased over 8 to 14 months.

What drives cost up in publishing specifically: the number of brands, because each has its own taxonomy, style and approval chain and they are never as similar as the executive summary says. Print, because InDesign and InCopy integration is real specialist work. Syndication, because every partner has a different feed spec and some still want NewsML. Paywall and entitlement, if you are metering or running a subscriber tier, since that touches every rendering path. And the archive, which is the line most likely to be underestimated.

What keeps cost down: launching one brand end to end before the second, and freezing your taxonomy before the build rather than during it.

Build versus buy, and when buying is the right call

Buy if you are digital only with one brand and modest volume. WordPress with a solid editorial workflow plugin, or Arc XP if you are large and digital only and have the budget, will beat a custom build on both cost and time to value. Buy WoodWing if your pain is genuinely print production and your digital side is simple, because reproducing what it does with InDesign is not a good use of your money.

Build when two or more of these are true. You run print and digital across more than one title on stacks that do not share a status model. Your commissioning and freelance budget lives outside the system that manages the work, so overspend is discovered late. You have had a rights or embargo incident that cost you money or access. You syndicate to partners and cannot answer where a piece went. Or you are carrying an archive that blocks every off the shelf migration quote you have received, which is a very common reason publishers end up building.

How to choose a developer for editorial systems

Ask them to whiteboard the difference between a commission, a story and a rendition. A developer who has done publishing work will separate these immediately and will ask which channels can have independent legal status. One who draws a posts table has built a blog and is about to discover print.

Ask directly what they will do with InDesign. The right answer is IDML and InCopy assignments with the layout staying in Adobe, not a plan to rebuild pagination in a browser. If they propose the second, they have not sat with a production team on a press day.

Ask how they will handle the archive migration and ask for the plan in tranches by traffic value with a redirect testing method. If migration appears as one line near the end of the schedule, the estimate is not real.

Ask who owns the code and the content model, in writing, before kickoff. You should own the repository, the infrastructure accounts and an export of your content in a documented structured format at any time. At Digital Heroes the client owns the code from the first commit, and for a publisher the content export clause matters just as much, because your archive is the asset and it should never be hostage to a vendor's schema.