Campaign file version control without final-final confusion
Keep campaign artwork, copy and delivery files identifiable with consistent names, visible status and a reliable record of what changed.
Separate a file's identity from its approval status
Version control for campaign files starts with a simple distinction. A version tells the team which revision they are looking at. A status tells them whether that revision is a draft, under review, approved or superseded. A filename containing the word “final” does not establish who approved it or whether a later correction exists. Keep identity and status explicit so the recipient can answer both questions.
A useful file identity describes the campaign and the asset, then adds the information needed to distinguish variants. This might include the language, placement, dimensions and revision number. Choose fields that match the team's actual work. A small campaign may need fewer fields than a regional launch with many formats, but both benefit from a naming pattern that does not depend on one person's memory.
Do not change the identity of an existing reviewed file by overwriting its contents. If the artwork changes, create a new version or use the application's version mechanism in a way that preserves the earlier state. Reviewers need to know whether the image they approved is the image now being delivered. An approval record attached to an ambiguous filename is difficult to trust operationally.
Choose a naming pattern that people can follow
Start with a short campaign identifier that remains stable throughout production. Add an asset description, a variant label and a version. For example, an invented pattern such as “autumn-workshop_poster_en_A3_v03” tells a colleague more than “poster-new.” The exact punctuation is less important than consistent use, predictable ordering and avoiding characters that cause problems in the team's storage or delivery systems.
Write a few examples for the common file types. Include a master concept, a language adaptation and a final export. Explain which parts of the name change when the artwork is revised and which remain stable. If dimensions are part of the name, make clear whether they are pixels, a standard paper size or another agreed production label. A number without units can create confusion.
Keep names readable. Extremely long filenames that repeat the entire brief are hard to scan and may be truncated in interfaces. Put detailed specifications in the campaign record and use the filename to identify the asset. The aim is that a person can distinguish files quickly while still finding the full context when they need it.
Create clear working, review and delivery areas
A designer's working files, review proofs and approved deliverables serve different purposes. Keep them distinguishable even if they live in the same campaign workspace. A reviewer should not have to guess which of several exports is ready for comments, and a recipient should not have to inspect the designer's entire working folder to find the authorised output.
Use folders, labels or a delivery manifest according to the tool's capabilities. The important rule is that the authoritative location for current review and final delivery is clear. Avoid maintaining several equally named “final” folders in different systems. If a file is copied for a specific handover, record where that package came from and when it was prepared.
A working area can contain experiments that are not suitable for distribution. Mark them accordingly and avoid sending the whole area as a shortcut. The final package should contain only the agreed deliverables and the information needed to use them. This reduces the risk that an old concept or unreviewed variant is selected because it happens to be nearby.
- Working files support production and exploration.
- Review proofs identify the exact revision awaiting comments.
- Approved deliverables contain the files authorised for use.
- Superseded files remain identifiable as earlier versions.
- A manifest explains the contents of the handover package.
Record changes at the level people need
A short change note can save reviewers from comparing every pixel without context. State what changed, why and which variants were affected. “Updated the event time on all English social assets” is more useful than “changes made.” Include the source of the correction when it matters, such as an updated brief or a decision recorded by the campaign owner.
Do not use a change note to replace review. A file can contain unintended changes as well as the intended correction. The note helps the reviewer focus attention, while the review still checks the actual result. If the change affects the central message or layout, explain that broader scope rather than describing it as a minor edit.
Keep a simple sequence of significant revisions. It should be possible to trace a final deliverable back to the reviewed proof and the decision that authorised it. The record does not need to narrate every mouse movement. It needs to preserve enough context to answer why a file changed and which decision applies to the current version.
Handle parallel variants deliberately
A campaign may have several valid current files: different languages, placements or audience versions. Do not treat them as a single linear sequence if they are genuinely separate variants. Each should have its own identity while remaining connected to the same master campaign. This prevents the latest upload in one language from being mistaken for the latest version of every language.
When the master changes, identify which variants inherit the change. A corrected date may affect all outputs, while a crop adjustment may affect only the portrait layout. Record the affected set and verify each resulting file. A global instruction such as “update everything” can conceal missed variants unless the team has a complete list against which to check.
Watch for branch divergence. A local team may change copy in its own version after the central master is approved. That can be legitimate, but the change should be visible and reviewed by the relevant owner. If files move outside the main workspace, establish how the updated version returns and how others will recognise it as current.
Link review decisions to the actual proof
Every approval should identify the asset and version it covers. If a reviewer approves a preview, preserve that preview or a reliable reference to it. When final exports are generated from the approved source, verify that they contain the same approved content and meet the required technical specification. The relationship between proof and deliverable should be explainable.
Avoid using an approval from one variant to cover another without checking the differences. A square graphic may be readable while a narrow banner is not. A translated asset may have different line breaks or a missing word. The version record should support the review process, not create a shortcut that hides those differences.
If a previously approved file needs correction, mark the earlier version as superseded and record the new review outcome. Tell the people preparing distribution which package has changed. Updating the workspace alone may not prevent someone from using a file they already downloaded. The campaign owner should coordinate replacement of affected copies through the agreed communication process.
Build a delivery manifest
A delivery manifest is a short list of the files included in a handover and their intended uses. It can contain the asset name, language, placement, format, dimensions, version and approval reference. Add any restrictions or instructions the recipient needs, such as which file is for print and which is a screen preview. The manifest should describe the actual package, not the planned package from an earlier brief.
Check that every listed file is present and opens correctly. Also check the reverse: every file in the package should be accounted for. An unexplained extra file may be an outdated version accidentally included during export. A missing file may be hidden by a manifest copied from a previous campaign. Comparing both directions makes the handover more reliable.
Keep the manifest with the delivered files and date the package. If a replacement is necessary, issue a clearly identified new package and explain what changed. This gives the recipient a practical way to confirm they are using the right set without searching through a long conversation history.
Keep recoverable history without creating clutter
Earlier versions can be useful for understanding decisions or recovering from mistakes. Keep them in an archive or version history with a clear superseded status. Do not leave them mixed with the current delivery files in a way that invites accidental use. A clean current view and a recoverable history can coexist.
Agree how long campaign materials are retained according to the organisation's needs and policies. The versioning process should not invent retention rules or delete files casually. Consider whether source assets, permissions and decision records need to remain connected to the final campaign. A final image alone may not contain the context required to reuse it appropriately later.
Review the structure after a campaign closes. If people repeatedly chose the wrong file, investigate whether the names, statuses or locations were ambiguous. Improve the pattern for the next campaign rather than adding more words such as “really-final” to compensate for an unclear process.
Example: replacing one incorrect language variant
Suppose a launch includes English and French square and portrait graphics. A reviewer discovers a typo only in the French portrait asset. The designer creates a new version of that asset, records the correction and requests the relevant review. The other three files retain their identities and approvals because their content has not changed.
The final manifest is updated to point to the corrected French portrait version. The old file is marked superseded, and the recipient is told exactly which asset to replace. This is clearer than renaming the entire campaign package without explaining the scope, or silently overwriting a file that someone may already have downloaded.
Frequently asked questions
Does every tiny change need a new version?
Any change to a file that has been shared for review or approved should remain distinguishable from the previous state. During private working sessions, the designer can use an appropriate working history. The key is preserving the identity of material that other people have reviewed, downloaded or relied on.
Should approval status be written in the filename?
It can be included, but a filename alone should not be the only approval record. Keep the decision maker, date and reviewed version in the campaign record. If status changes, make sure the current delivery location and manifest reflect it so an old filename does not continue to imply approval.
Can a shared campaign workspace replace naming conventions?
A workspace can make versions and context easier to find, but clear names still help when files are downloaded or handed to another team. Campaign Bay keeps campaign work together; agree naming and delivery conventions that remain understandable both inside the workspace and in the recipient's own workflow.