Build an InDesign Preflight Profile for a Treatment Handoff

By pitch.dogFoundation11 min read20 September 2026

Advertising

A green indicator in InDesign's Preflight panel tells you one thing: the conditions you selected did not fire on the content you scoped in. That's a real and useful sentence. It's also narrower than it looks. A profile can be watching four kinds of problem out of twenty, over three pages out of eight, with a checkbox somewhere deciding whether hidden layers count at all. The light is still green.

So the job isn't to switch preflight on. It's to build a small profile whose rules match what this particular handoff actually needs, and then to poke at it hard enough that you know what its silence means. The treatment goes out either way. The difference is whether you know what you checked.

Translate the handoff into conditions the software can check

Start with the thing you're actually sending. Not "a treatment" — the artifact: a PDF the client opens on a laptop during a meeting, clicks through, and probably forwards to two colleagues who weren't in the room. That sentence already rules things in and out.

What can go wrong that the client will actually see:

A paragraph that runs past its text frame. The overflow — the part that didn't fit — is simply absent from the page. The client reads an argument that stops mid-thought and concludes you can't write. InDesign calls this overset text, and it's one of the cheapest things to check and one of the easiest to miss, because in the editor the text still exists. It's just invisible.
A missing link. Placed images aren't stored inside the InDesign file; the file holds a pointer to the picture on disk. Move the folder, rename the file, open the project from a different drive, and the pointer dangles. The export falls back on whatever preview is cached, which is usually too coarse to read at full size.
A font that isn't on this machine. Substitution changes your line breaks and sometimes the whole feel of a headline.
Image resolution below what the reading size needs. Note the "what the reading size needs." That's where people wreck a screen profile, by importing a print one.

And what no profile can check, because no machine can: whether the client's name is right, whether the claim on page 4 is true, whether you have permission to use the photograph, whether the tone suits this room. Hold those separately. They're the whole point of the human pass, and no amount of green replaces them.

Here's where a print profile betrays you. A press-ready profile is full of sensible conditions: 300 ppi minimum image resolution, CMYK-only color, minimum stroke width, total ink coverage. Every one of those is a considered answer to a question a printing press asks. A screen PDF isn't asked any of them. Run that profile against your treatment and you'll get maybe forty warnings, none of which describe a change you would make. That list is worse than no list, because it teaches you to close the panel without reading it — and that habit will still be there the day a real warning shows up.

If the same treatment also goes to a printer as a leave-behind, that's a second profile for a second output, not a beefed-up first one.

So apply one filter to every condition you consider: if this fires, is there a change I would actually make before sending? Yes, select it. No, leave it off, and write down why. The written reason is worth more than it sounds. It's the difference between a decision and forgetting.

Create a named profile and confirm its coverage

InDesign ships with profiles, and you can add your own. Build the new one by duplicating something close and editing it rather than starting from a blank slate — you'll spend less time wondering whether you forgot a category.

Name it for the job, not for yourself. Marchmont screen PDF — v1 beats preflight copy 2 in every way that matters, because in three weeks the name is the only thing telling you what those settings were tuned for.

Then notice that a profile is three settings wearing one hat.

The rule set. Which conditions are selected at all. This is what people mean when they say "the profile."

The content scope. Which parts of the document those rules get applied to. Adobe's documentation for the panel covers layer scope, nonprinting objects, and pasteboard material, and the practical consequence is blunt: change the scope and the reported issues change. A hidden layer that never reaches the export, a nonprinting object, a frame parked on the pasteboard — each is either in the report or out of it, and that's a decision you make, not one the software makes for you.

The display filter. The panel lets you set a page range that governs which errors get reported. Adobe describes this as a filter on what's listed and notes that it doesn't turn preflight off across the rest of the document. Which means a short list under a narrow range is not evidence about anything. Before you read an empty panel as good news, look at what range it's set to. This is the most common way a designer misreads a clean result.

If you want the pasteboard and hidden layers excluded, exclude them — but say so out loud, because someone downstream will read your report as if it covers the whole file.

Here's a concrete case. Call it fictional; it's assembled to make the mechanics visible, and no InDesign file was opened to write it.

A designer inherits marchbank_treatment_v4.indd, built months ago for a pitch to Marchbank Coffee, and is told to reuse it for Marchmont Coffee. She swaps the body copy and rebuilds the imagery. What's left behind:

Page 5, the approach section: a body paragraph is overset. Its last two lines sit outside the frame, invisible on the page and absent from the export.
Page 2: the hero image link is broken, because the project folder got reorganized and nobody re-linked it.
A hidden layer named ARCHIVE — v3 copy, holding the old version's text, including a frame that oversets too.
The cover, and the running footer on every page, still read Marchbank Coffee. Spelled perfectly. Wrong company.

Now test the profile — on a duplicate, deliberately.

Making your own scratch copy first is the part people skip. Plant a fault you control: shorten a frame until its last line oversets, move one linked image to a different folder so the link breaks. Run the profile against that. Now you know precisely where the problems are, which is the only condition under which a preflight report can teach you anything. When a planted fault doesn't appear, you have exactly three suspects: the condition isn't selected, the scope excludes that object, or the display filter is hiding it. Three different fixes.

Then repair, in the duplicate, and run it again. Relink the image. Resize the frame or cut a sentence. Watch the entries leave the list. And then look at the page, because this is where a cleared flag fools people. The relink may have attached a low-resolution stand-in that satisfies the link check and still looks soft in the meeting. The resized frame may have solved the overset by removing a clause the argument needed. Preflight tells you a condition changed. It doesn't tell you the page got better. That look is the human half of the job, and it doesn't shrink because the panel went quiet.

Now run the same profile against the real inherited file, and the coverage question stops being theoretical. With the profile scoped to include hidden layers, the archive layer's overset belongs in the report — text that will never reach the client's eyes. Scope hidden layers out and it won't appear. Narrow the panel's page range to pages 1–2 while you review the opening, and the page-5 overset won't be listed either, without anyone having fixed anything. Same document, three different reports, each accurate about the settings it was given.

And the client name? Nothing. Spell-check passes it, because Marchbank is a perfectly good word. No preflight condition can help, because "correct company name" isn't a property of the file. It's a fact about the world that lives in your assignment details. Confirm it against the brief, out loud, with a person who knows which company is paying. That check belongs on the human list, next to "the claims are accurate," "we have rights to these images," and "the tone is right."

Make the profile travel without assuming it takes control

A profile you build and never share is a personal habit. If the file leaves your machine, the settings need to leave with it, and there are two routes.

Export it as a profile file — the extension is .idpp — and hand it over alongside the document. The recipient imports it and it joins their list.

Embed it in the document, where it travels inside the file itself. Tempting, and Adobe's documentation is explicit about the limit: embedding a profile doesn't force the recipient to use it. The profile arrives; the selection doesn't. Someone can open your file with an entirely different profile active and produce a report that has nothing to do with yours — and both reports will be correct about what they checked.

So when the file comes back, or when you open it on the other machine, the first thing to confirm is which profile is active, before you read a line of results. And put the expected profile in the handoff note, in one line: which profile the file was checked under, what it found, and — the part that saves arguments — what it does not inspect. Something like: "Delivered under 'Marchmont screen PDF — v1.' Caught overset on p5 and a broken hero link on p2; both fixed. Not checked: the client name on the cover — please confirm against the brief." That note beats a clean panel, because it tells the reader exactly where the machine's authority stops.

Two small frictions are worth knowing. Adobe's own documentation for this feature isn't perfectly consistent about whether the command reads Preflight or Profile in a given menu, and labels shift between versions, so read the actual command in the version in front of you rather than trusting a tutorial. And a clean preflight result describes the source document. It says nothing about the exported PDF, which is a separate object with its own problems — page count, image handling, file size, how the links behave for the recipient. Preflight the source, then open the thing you're actually sending.

None of this turns preflight into an approval gate, and it shouldn't. A useful profile is narrow on purpose: it watches a short list of conditions, over content you've declared, under a range you've set, and it speaks up when one of them trips. What you get is a named, repeatable check with a visible boundary around it. What it still needs from you is the part it can't do — knowing which company is paying, and looking at the page after the light turns green.

Frequently asked questions

What does a green Preflight indicator actually promise?

It means the selected conditions did not fire on the content you scoped in. It does not mean the document is problem-free: the profile can be watching a subset of conditions, over a page range, with hidden layers or pasteboard objects in or out of scope. Before reading an empty panel as good news, check what range is set.

Why can a print-ready preflight profile be a poor fit for a screen PDF?

Conditions such as 300 ppi minimum resolution, CMYK-only color, minimum stroke width and total ink coverage answer questions a printing press asks. A screen PDF is not asked those questions, so running a press profile can produce many warnings that would not lead to changes. That teaches you to close the panel without reading it.

When a planted fault does not show up in preflight, what should you suspect?

There are three suspects: the condition is not selected, the scope excludes that object, or the display filter is hiding it. Those are three different fixes, so test on a duplicate and plant known faults to learn what the profile can see.

Can preflight catch a wrong client name on the cover?

No. A correct company name is not a property of the file. Spell-check can pass a wrong but real word, as with Marchbank versus Marchmont. That check belongs on the human list and should be confirmed against the brief with someone who knows which company is paying.

Does embedding a profile force the recipient to use it?

No. Embedding puts the profile in the document, but it does not force the recipient to use it. Someone can open the file with a different profile active and produce a report that is accurate about what it checked. Confirm which profile is active before reading results, and state in the handoff note what the profile does not inspect.