Build an Episode Guide From Structured Copy Without Reformatting Every Entry
Build an Episode Guide From Structured Copy Without Reformatting Every Entry
Ten episodes are approved. The summaries are written, the stills are chosen, and the guide still isn't built, because building it means pasting the same layout ten times and nudging it ten times. Somewhere in that process episode 4's still ends up above episode 5's summary, and you find out after it's published.
The way out isn't a better template. It's a change in who owns what. A structured source holds the episode material. One layout points at that source. The generated guide is then something you inspect, not something you trust.
The shape of the job: one source record per approved episode, one field-linked layout, a preview pass over the cases most likely to break, a merge you actually read, and one source change re-merged to prove the thing repeats. Adobe's help page on setting up target documents describes the same skeleton — one data source, fields inserted through the feature rather than typed, previewed against real records — and that page is worth reading in your own version of the application, because the menus move between releases while the skeleton doesn't.
What the skeleton cannot do is approve anything. A merge that runs cleanly tells you the plumbing worked. It says nothing about whether the copy is approved or whether that still belongs to this episode. Those stay your job, and the workflow's real value is that it makes both failures visible before a reader sees them.
Give every episode one record
A row per episode, and inside that row everything the page needs: a stable identifier, the title, the approved synopsis, and an image reference.
The identifier is the piece people skip, and it's the piece that makes verification possible. Something like HBR-102 — a series code and a number — lets you check a page against a record without rereading the prose. Don't use the title. Titles get retitled. Don't use "Episode 2" either; it's accurate until someone inserts an episode ahead of it, and then it's quietly wrong on every page after.
Build the sheet so a merge can read it, not so it looks tidy on screen. The classic wreckage is a title in one row and its synopsis in the next, or a merged cell spanning two rows, both introduced because the layout looked cramped. The merge reads rows and columns. It has no opinion about how nice your header looks.
Keep the header names plain and identical to what the layout expects. A misspelled header is a field that comes through empty, and an empty field looks a lot like a field you forgot to place. And remember that what travels is the content, not the display. Bold, a cell colored to flag a question, a date shown as "March 3" — none of that reliably crosses into the page. If a note to yourself lives only in the formatting, it doesn't live anywhere.
One more discipline: the synopsis cell holds approved copy. Doing a light edit in the sheet feels harmless and turns the source into a place where writing silently changes. If the writer revises something, that's a deliberate source update — which is exactly the event you'll want later, when you test whether the workflow actually repeats.
Build one layout, with fields inserted rather than typed
Start with one episode per page. That keeps the demonstration bounded; if you later want two per page, the same record feeds two frames and the source doesn't change. The layout absorbs that decision.
Now insert fields from the merge feature itself. Typing something that looks like a field — <<synopsis>> — produces literal text, and literal text merges into the same literal string on every page. That failure is nastier than an empty frame, because the layout looks correct right up until someone reads it. Adobe's page is explicit that fields are inserted through the feature; take it literally.
The distinction to hold in your head is static versus variable. The word "Episode" is static. A number, a title, a runtime — variable. Typing EPISODE 2 in the corner of the page is a nice-looking coincidence that becomes a lie the moment the merge runs or the numbering shifts. Anything that should differ per record has to arrive from the source.
Image frames work the same way: insert the image field into a frame that's already sized and positioned. The frame's geometry is a layout decision and belongs in the target. The path inside it is a source decision and belongs in the record.
Then do the small thing that makes the whole verification pass possible. Put the identifier field in a predictable corner of the page, small, in the footer or the margin. Now you can flip through the output and match each page to its record at a glance, which is the difference between a ten-minute check and an afternoon.
Preview the three cases that break a merge
Preview against real records, not against your hopes. Before you merge, make sure the source contains the three shapes that cause trouble: a short synopsis, a long one, and a record with no image at all.
To make this concrete, here's a paper example. It's invented for illustration — three fictional records for a fictional series called Harbor, not a job anyone ran — so treat the outcomes as the ones to watch for rather than as a report from a screen.
| ID | Title | Synopsis | Image |
|---|---|---|---|
| HBR-101 | Low Tide | about 30 words | low-tide.jpg |
| HBR-102 | The Long Way Around | about 170 words | long-way.jpg |
| HBR-103 | Signal Fire | about 60 words | (empty) |
Note that the two images are deliberately unmistakable — think cold blue against warm yellow. That's not decoration. If both stills are foggy gray coastlines, you can pair them wrongly and never notice. Give each record a visual you'd recognize from across the room, and crossover becomes perceptible instead of theoretical.
Previewing that source, three things surface:
HBR-102 doesn't fit. A hundred and seventy words in a frame built for a paragraph of forty means overset text — the excess simply isn't on the page. This is a layout problem.
HBR-101's frame is empty even though a still exists. The file was renamed during post, so low-tide.jpg no longer resolves. This is a source problem: the reference is broken.
HBR-103's frame is empty because there is no still yet. This is neither. It's an editorial state — the image hasn't been approved.
Two of those empties look identical on screen and need completely different responses. The broken path gets fixed in the source. The absent still does not get fixed by reaching for a similar image from another episode, because the moment a placeholder looks plausible, you've hidden a decision that belongs to someone else. If you want the gap to read as intentional, that has to come from the source too — a status field, or an explicit blank the layout knows how to handle. A static caption living in the target won't help, since it would print on every page, including the ones with images. Whether your tool can handle that conditionally is something to confirm against your own version rather than assume.
Merge, then read the output
Merging produces a new document. What you do next is the part that separates a workflow from an accident.
Use whatever overset report your version offers. If it offers none, the misshapen page is the report, and honestly that's fine — but either way, warnings are not verification. A missing-image alert tells you a link didn't resolve. It cannot tell you that the image which did resolve belongs to this episode. That's the crossing problem, and only deliberate checking catches it.
So check every page on three points: this page says HBR-102, it shows HBR-102's title, it carries HBR-102's still. It's dull. It's also the entire job. Then export the reading file and check that the text is present and visible — a guide can look finished while sitting a paragraph short, because text that doesn't fit a frame isn't in the export either. While you're there, look for orphaned captions pointing at empty frames, and for any label that came through blank and left a stray colon stranded on the page.
Fix source errors in the source and layout errors in the target. Resist the shortcut of shortening an approved synopsis to make a frame behave. The frame is the pliable thing; the story copy isn't, unless an editor says so.
Prove it with one source update
A merge that worked once proves the plumbing isn't actively broken. It doesn't prove the connection is live. For that you change something small and watch it arrive.
Take the revision a writer would actually send: a character name in HBR-102's synopsis was wrong, and the correction is approved. Edit that one cell in the source. Reconnect or refresh the data source in the target. This is also where the preview's layout problem gets settled, because HBR-102's frame was enlarged in the target to hold the longer synopsis — a layout fix, applied where layout fixes belong. Then merge into a new file — guide-v2, not over the top of the first one. Compare.
HBR-102's page should show the corrected text, and the full synopsis should now fit, since the frame that overset in the preview has room for it this time. HBR-101 and HBR-103 should be untouched. If the revision didn't appear, there are three real causes and they're all easy to find: you edited a different source file, you're looking at the older output, or the target is still pointing at a stale link. Keeping guide-v1 next to guide-v2 is how you check what actually changed — and how you show someone else, without explaining.
Why bother with this step at all? Because three well-behaved records can merge correctly by luck. One change, one regeneration, one comparison across neighboring entries turns luck into a workflow you can hand to someone else.
What you're left holding
Four things: a source that owns the copy, a target that owns the layout, a reviewed output, and one demonstrated update. When a long entry doesn't fit, the failure shows up as a layout decision instead of missing paragraphs. When a still is absent or wrong, the identifier in the corner makes it obvious before the reader finds it. And when the writer revises something in March, you change one cell and regenerate instead of rebuilding ten pages by hand.
None of that gets you out of approving the material. A merge publishes what you gave it. Keep the writing decisions in the source, the design decisions in the target, and the guide becomes something you produce again rather than something you type again.
Frequently asked questions
What is the recommended shape of the episode-guide workflow?
One source record per approved episode; one field-linked layout pointing at that source; a preview over short, long, and missing-image cases; a merge that is read and checked page by page; and one source change re-merged to prove the connection repeats. A clean merge only proves plumbing, not approval.
Why use a stable identifier such as HBR-102 instead of the title or 'Episode 2'?
Titles get retitled, and 'Episode 2' becomes quietly wrong if an episode is inserted ahead of it. A stable identifier lets you check a page against a record without rereading prose, and placing it in a predictable footer or margin makes verification a glance instead of an afternoon.
How should fields and images be placed in the layout?
Insert fields through the merge feature rather than typing them; typed placeholders merge as literal text. Keep static words like 'Episode' in the layout, but send anything variable — number, title, runtime — from the source. Insert an image field into a frame whose size and position are layout decisions, while the path is a source decision.
What three preview cases break a merge, and how should each be handled?
A long synopsis can overset the frame — a layout problem, fixed in the target. A broken image path, such as a renamed file, is a source problem, fixed in the source. A missing still because no image is approved is an editorial state; do not substitute a similar image, because that hides someone else's decision. Two empty frames can look identical and need different responses.
What does one source update demonstrate, and what are the limits?
Editing one cell — for example, correcting HBR-102's character name — then refreshing the source and merging into a new file such as guide-v2 should show the correction there while neighboring entries stay untouched. That turns luck into a workflow. The paper example is invented for illustration; merge warnings do not confirm that a resolved image belongs to the right episode, and conditional handling should be confirmed in your own version.