Why PowerPoint Version Control Breaks Down in Life Sciences
On a Tuesday in late September, a scientific communications manager updates slide 22 of the core scientific deck. A new data cut has moved one figure in the pooled safety table, the footnote now cites the 2025 publication instead of the 2024 congress abstract, and medical, legal, and regulatory review has cleared the change. She saves the deck as v4.2, records the change in the tracker, and emails the field medical team with the new file attached. As far as the document is concerned, the job is finished.
Slide 22 also sits in the Northeast MSL regional deck, the advisory board pre-read that goes out Friday, the nurse educator training set, and a symposium deck a vendor built in July. Nobody copied it carelessly. It was the approved slide and the right one for the job. None of those decks changed on Tuesday. The old safety table will be presented at the advisory board on Monday by an MSL who read the email, believed the deck on her laptop was current, and had no way to check.
This is not a training problem. It is a structural gap in how PowerPoint version control works, and it shows up in life sciences more than almost anywhere else because approved slides get reused so widely.
Document version control tracks the wrong object
Most Medical Affairs teams already practice version control: a version number in the filename, a change log on a hidden first slide, check-in and check-out on SharePoint, a PDF of the reviewed deck attached to the approval record. These habits answer the question they were built to answer: what state this file is in and how it got there.
The trouble is that the file is not the thing that gets reused. Slides are.
That is why file version control can be working perfectly while slide version control is still broken.
A core deck of sixty slides is rarely presented as sixty slides. It gets pulled apart. An MSL takes twelve for a KOL visit. A congress team takes four for a symposium and adds their own. Every one of those pulls creates a new file, and every new file starts its own version history, its own filename, its own approval trail. The history of the core deck does not follow the slides out the door.
Slide version control asks a different question: what version is this slide, where did it come from, and where else does it live now. Document version control cannot hold that information because it does not know the slide exists as a separate object. To SharePoint, a .pptx is one file with one modified date and one version number. The slides inside it are invisible to the history. This is the same argument at the center of what a governed slide library actually is, applied to the one discipline most teams believe they already have covered.
Why a copied slide loses its history
Copying a slide is a content operation, not a reference operation. When a slide moves from one deck to another, the destination receives the shapes, text, images, and layout. PowerPoint copy and paste does not preserve a governed relationship to the source deck, its approval record, or its version history. That connection exists only in the memory of the person who made the copy.
Memory fades fast. Decks pass between MSLs when territories change. Within a quarter, nobody can say which slides in a field deck were copied from the core, which were modified after copying, and which were built locally. A slide edited in the field after approval is visually indistinguishable from the one that cleared review.
Teams try to patch this. Some add an approval code to the footer. Some keep a spreadsheet mapping slides to decks. Both depend on every person, every time, doing the extra step, and both fail the first time a slide is copied by someone who did not know the rule. A footer code is also just text. It copies along with the slide and stays put when the source is superseded, so the code on an outdated slide goes on asserting that it is approved.
How the old slide keeps circulating
The copies keep getting copied. A vendor’s symposium deck becomes next year’s starting point. The regional deck is forwarded to a new hire as the one everyone uses. Each generation carries the old slide 22 forward, one more step removed from anyone who would recognize it as outdated. This is the mechanism behind field decks drifting out of date, seen from the version-control side.
Meanwhile the science underneath keeps moving. Data cuts update. Labels change. In pharmaceutical presentation management, a stale slide can create compliance risk or put outdated scientific information in front of an HCP. The team that owns the core deck did everything right and still cannot answer the auditor’s question, which is not whether the slide was updated but where the old one is still being shown.
What a slide-aware process has to be able to detect
If version control is going to work at the slide level, it has to answer a short list of questions that document version control cannot.
Four questions document version control cannot answer
- Which version of this slide is the current approved one, and what changed between versions.
- Which presentations, in the library and in the field, contain an earlier version of it.
- What evidence and references the slide rests on, and whether those have changed.
- Who approved the slide, when, and whether that approval still holds after the latest edit.
Each of these requires the slide to carry its own identity. Version, approval state, and evidence linkage have to be attributes of the slide itself, not of the file it sits in, and they have to survive the copy into another deck. Once they do, finding where the old slide is still in use stops being a manual audit and becomes a lookup.
This is the design principle behind SlideSource Library. The slide, not the file, is the unit that carries version, evidence, and approval status. When a slide is reused from the approved pool into a new presentation, it keeps its version history, its approval state, and its reference linkage. Because the slide retains its governed identity, a superseded version can be identified rather than trusted simply because it looks right, and each slide carries a usage view listing the presentations it appears in. The where-else question has an answer on the screen.
Decks that have already left, the ones sitting on laptops since the day they were downloaded, are the job of vCheck. It takes a downloaded or in-the-field deck, checks it against the library, and reports the slides in it that have been superseded, that have had approval rejected, or that have been removed from the library entirely. For the advisory board deck at the top of this article, that replaces hoping everyone read the email with a check that names the outdated slides before the deck is presented.
Library is not a replacement for Veeva Vault. Where Veeva Vault is the system of record for approved material, Library works alongside it and governs the PowerPoint layer, where slides are assembled, reused, and taken into the field, which is exactly where file-level version control has no visibility.
Moving from manual checking to slide governance
Teams do not have to rebuild everything at once. The move from manual checking to slide governance has a natural order.
- Acknowledge that the current process cannot answer the where-else question, and stop expecting a naming convention to get there.
- Establish an approved slide pool as the single place reuse happens from: a set of slides, each with its own version and approval state, rather than a folder of decks. Duplicate detection matters here, because a library usually starts with the same slide present in many decks under many filenames, and those have to be reconciled before slide-level history means anything.
- Change what happens when a slide is superseded. Instead of an email announcing a new version, the update becomes something the system knows about. Anyone looking at the slide can see which presentations contain it, and a presentation still carrying the old version is recognized as behind rather than trusted on sight. For decks already in the field, vCheck works from the other direction: the deck an MSL actually has is checked against the library before it is shown.
- Scope who can share what. Controlled sharing, including portals for outside consultants, keeps copies from escaping to places no check will reach.
None of this removes the need for review, or for Vault, or for judgment. What it removes is the gap between updating the slide and knowing where the old slide is. For MSL deck version control, that gap is the whole problem. Document version control was never built to close it, and no amount of filename discipline will make it.
Common questions
What is the difference between document version control and slide version control?
Document version control tracks a whole PowerPoint file: its version number, who changed it, and when. Slide version control tracks each slide as its own object, with its own version history, approval state, and references, so those attributes stay with the slide when it is copied into another deck. Document control can say what changed in a file. Only slide control can say where an earlier version of a slide is still in use.
How can a team find every presentation that still contains an outdated slide?
With file-level tools it cannot be done reliably, because a copied slide carries no link back to its source and PowerPoint files do not expose slides to search by version. It takes a system that stores each slide with its own identity and approval state. For presentations held in the library, a slide usage view lists the ones that contain it. For decks already downloaded or in the field, a check of the actual file against the library, such as vCheck in SlideSource Library, reports which slides in it have been superseded, rejected, or removed.
Does SharePoint version history track individual slides in a PowerPoint deck?
No. Native SharePoint version history keeps version history for the .pptx file as a whole, so it can show who saved the deck and restore an earlier copy. It does not know which slides changed, where those slides came from, or which other decks contain copies of them. A slide pasted into a new deck starts a fresh history in that file, disconnected from the original.
Do MSL teams still need Veeva Vault if they use a governed slide library?
Yes. Where Veeva Vault is the system of record for approved material, Library works alongside it and does not replace it, and Vault keeps the approval record itself. A governed slide library such as SlideSource Library operates on the PowerPoint layer, where slides are assembled into decks, reused across teams, and taken into the field.
See SlideSource Library in action
See how SlideSource Library keeps scientific slides current, approved, and reusable across your teams.