Sharing one b-roll library across a small team

StoryFolder — 2026-09-02

Part of: How to catalog b-roll across multiple clients

Last updated: 2 September 2026.

Three of you shoot, two of you cut, and the footage already sits in a shared cloud drive with folders for interiors, exteriors, departments and events. Somebody asks for the wide of the loading bay from last spring, and the folder tree cannot answer. Next month a freelancer starts on that same job and every filename on the drive looks like C0042.mov. A team library is really five separate decisions: where the original files live, what people browse when the originals are too big to move, where the searchable notes live, who is allowed to see what, and what somebody actually receives when they need to cut with it. Buy or build each layer on its own, because one product almost never does all five, and the two that most often get collapsed together are storage and search.

StoryFolder is the search layer, and it runs on one person's machine. It keeps its own local database and points at your files where they already sit, which is why it still works with the drive unplugged. The team gets the outputs: a published board, a spreadsheet, a PDF. The storage, the drive inventory and the proxies your NLE cuts with are somebody else's job, and this page is mostly about which somebody.

What does a shared b-roll library actually have to share?

Five layers, each with its own owner and its own way of failing: the original media, the browse copies light enough to scrub over a home connection, the index of thumbnails and searchable notes, the access rules deciding who sees what, and the delivery package somebody actually receives when they need to cut with it.

A folder tree solves location. Interiors, exteriors, departments, events: pick one, and the shot that is a drone exterior of a department event is filed under exactly one of them, and the person who did not file it looks in the other two. Multi-axis questions want fields, one per axis, all searchable at once.

The reverse trap is worse and more common. A visual index gives you the multi-axis search and gives you nothing at all about governance: which copy is canonical, who is allowed to delete, what happens on the day someone's laptop dies. On REDUSER in 2016, a poster whose shop had grown to two shooters and two editors described trying Lightroom, finding it would not take MXF, falling back to Finder comments, and then watching those comments get stripped when the files moved between machines. That is the whole problem in one thread: the notes were real, and they were attached to the one thing that does not survive a transfer.

Attaching notes to the file is a reasonable instinct and it fights the network. Finder tags are extended attributes, and they routinely do not survive an exFAT or SMB copy. Spotlight indexes filenames, tags and typed comments, and does not index what is inside the video. Anything you type into a shared drive's own web interface belongs to that vendor's search box and comes out through that vendor's export.

So the working rule for a small team is that the index has one owner and one home, and the storage layer is treated as media only. Agree the schema across everyone, agree who types it, and keep the storage doing the one thing storage is good at. The field set that survives client work is the schema question the cataloging guide covers in full: Client, Job#, Location, Content Type, and a text field naming the folder the original sits in, so the path becomes something the search box can read. Pick the field type per axis while you are at it: a Dropdown holds one of its own options, so Content Type comes back spelled the same way across three jobs, and a text field will take whatever anybody types.

Write the definitions down at the same time, because a field name is obvious to the person who invented it and ambiguous to everyone else. Does Content Type mean the camera setup or the deliverable, and does an empty Release form mean not cleared, or not checked yet? Right-click a field in the shot inspector, choose Add description…, and answer the placeholder's own question, "What is this field for, and how should it be filled in?" That description lives with the schema, so the next person to fill the field reads the same rules you did. See documenting each metadata field.

Where does the library live, and what can the team open?

On the machine of whoever imported the footage. StoryFolder keeps a local database and leaves your files where they are, so the index needs no server and no upload, and it has one owner. Nobody else opens it. The team receives what that person publishes or exports.

StoryFolder writes a local database.sqlite alongside its cached frames and browsing proxies, and a local import is never copied into the app. That is why the index survives the original going back on a shelf, why it needs no server of its own to search, and why the library itself is a single-owner object: one person types, and everyone else opens what that person sends out.

What goes out is specific. In the editor toolbar, Get Share Link opens a popover headed Publish your storyboard. Leave Include notes & data on, pick Public, Unlisted or Password, click Publish, then Copy link. The recipient opens a view-only page at /b/<board id> with three layout modes. What gets uploaded to it is the shot grid, every shot-scoped field keyed by its own title, and the per-shot transcript. There is no video player on that page for a local-file source, and 77% of paying-customer boards are local files, from an internal analysis of 813 boards across 295 paying customers. Password protection is Pro.

Include notes & data is all or nothing: it publishes every shot-scoped field on the board. If a Job# or an internal rating is not something the client should read, archive the field before publishing rather than assuming the link will hide it. The spreadsheet and PDF exports do let you choose fields; the published link does not, and generalising from one to the other is the mistake that leaks something. See publishing a board.

Which storage setup fits a small team?

Three shapes cover almost every three-to-ten-person shop, and they differ mostly on who does the copying.

That last cost shape is the one the forums argue about. Across at least four separate r/editors threads, editors pricing enterprise media management landed on the same phrase: per month, per terabyte, per user. On one of those threads a poster summarised the category as "true enterprise products. Great for a big post house, but really pricy for smaller outfits. My mini soapbox about MAM is that it will only ever be as good as whoever is keeping it…" (r/editors). Prices move; read those for the shape of the billing, not for a current number.

Only the MAM column even claims the archived-drive question, and it claims it inconsistently. Someone on r/videography described the version most shops actually run: "I offload completed projects and have a spreadsheet of what's on which drive (I have 40 drives in a closet now, going back about 16 years)."

StoryFolder does not close that gap. It records one absolute path per import and nothing about the volume that path was on, so it can tell you a shot exists and cannot tell you which external it is on. It has no watch folder and no batch ingest, taking one video per drop. It writes an internal browsing proxy for its own grid and no proxies for your NLE. Cataloguing a shelf of unplugged disks is what NeoFinder and DiskCatalogMaker are built for, and running them alongside the index is a perfectly sane setup: one tool answers "which drive", the other answers "which shot".

The same split decides how footage reaches somebody outside the team. Copying the media and deciding what they are allowed to delete belong to your NAS, your cloud drive or a courier. What you can do is make the two line up. The folder value in your index is a string you typed, so it means whatever the folder was called on your machine: preserve those folder names in the copy you send, and put a plain drive or folder manifest next to the sheet when the material is split across more than one volume, because nothing in the index generates one.

Your own copy of the index survives all of this. A renamed file or an unplugged drive leaves the project browsing off its cached frames, with Locate File… there to reconnect the original, which the cataloging guide covers in full. That is a repair for whoever owns the library, and a recipient outside the team never had one.

Which MAM triggers are team-shaped?

Three: two people needing to write to the same catalogue at once, access that has to differ by person rather than by link, and centralised ingest with an audit trail. A single-owner index has no answer to any of them beyond taking turns. Whether you need a MAM at all is the prior question, and the guide to cataloging b-roll without a MAM settles it.

What should the shot log spreadsheet contain?

One row per shot, carrying a thumbnail, your own metadata columns, timecodes and exact frame bounds. In the app: open Export, tick Spreadsheet / Shot List, tick Images, choose which fields become columns, and run it. You get Shot List/Shot List.xlsx, worksheet Shot List, in the destination you picked.

The columns come out in a fixed order:

The two image columns appear only when frame images are being written at all, which the Images, Storyboard and online-storyboard options each satisfy. Only shot-scoped fields become columns, so a project-level Client typed once for the whole import is kept out of a sheet where it would repeat down 400 rows as the same value.

Tell the recipient to work from First Frame and Last Frame when a boundary has to be exact. Those two are integers counted in the file itself, so they survive any conversation about frame rate, and the timecode columns run from the file's own start.

For somebody who never opens the app, paste the field definitions you wrote into the schema at the top of the sheet yourself; the export carries your headers and not your reasoning.

A sheet like that is a specific, old request. On Creative COW in 2017, Alan Barker asked simply: "Is it possible to print the Premiere data out as a log?" Nobody answered him. Seven years earlier, in the same forum's b-roll library search thread, a poster had already described accumulating more clips than anyone could hold in their head. Both wanted an artefact that leaves the software: a list of what exists, with pictures, that opens anywhere.

A .csv twin of the workbook lands in the same folder. Point a script at it; it holds the same columns and no images.

Both halves of this are Pro: creating your own fields, and exporting the spreadsheet they become columns in. The storyboard PDF, the image export and public links are included on the free tier, which gives you 3 boards holding 12 shots each, enough to see whether the sheet is the artefact you want before an archive depends on it. See exporting a spreadsheet.

Should you send a link, a PDF, or the spreadsheet?

Send the spreadsheet, plus a written line saying where the media is. Reach for the other two when the recipient only has to look at the footage.

What none of them carries is the media. The link points at a page, the spreadsheet points at nothing, and moving the actual files stays a storage-layer job.

How do you test the handoff before anyone relies on it?

Hand the package to somebody in the building who did not shoot the job, and give them three lookups. Fifteen minutes, and it is the only part of this that finds the gaps. This assumes you have already run the one-reel pilot in the guide to cataloging b-roll without a MAM.

1. Find a shot by job. Filter or sort the sheet to one Job# and pull the three best b-roll shots for it. Fails when the field was filled on some shots and not others.
2. Get from a row to a file. Take one row and locate the original on the drive you sent, using only the folder value and the filename convention. Fails when the folder field says something only you would recognise.
3. Match the bounds. Open that original and confirm the shot really starts at First Frame. Fails when the sheet came from a different cut than the media you shipped.

The test passes when they finish all three without StoryFolder installed and without messaging the person who shot it. What it exercises is the package, which is the only thing the recipient will ever hold.

What the editor still does in the NLE

All of it. Nothing here comes back out as an EDL, XML, FCPXML or AAF, so the selects somebody marks in the sheet get assembled in their timeline the normal way, and their notes reach you as a conversation.

FAQ

Does StoryFolder upload the original .mov to its library? No. A local import stays at its existing path on your disk; the app writes its own cached frames, a browsing proxy and a local database.sqlite.

Can two editors open the same StoryFolder library? No. The library is a local database on one machine with no sync layer, so one person owns it and the rest of the team receives its outputs.

Can a shared link play my local footage? No. The published page has no video player for a local-file source, and 77% of paying-customer boards are local files.

Can a shared link include our notes? Yes. Include notes & data publishes every shot-scoped field by title, plus the per-shot transcript. It is all or nothing, so archive anything internal first.

Can someone open the shot log without installing StoryFolder? Yes. It is a standard Excel workbook, Shot List.xlsx, with a worksheet named Shot List.

Can the exported spreadsheet include pictures? Yes. Turn on Images and each row embeds a 200 px-wide frame next to your own field columns.

Are the spreadsheet timecodes source timecode from the camera? No. They are elapsed from the start of the file, and First Frame and Last Frame are the exact integers to work from.

Can a freelancer send the spreadsheet back with their picks in it? No. There is no spreadsheet import and no EDL, XML, FCPXML or AAF round-trip, so their selections come back however you already collect notes.

Which parts of this cost money? Custom fields and spreadsheet export are both Pro, and the handoff package needs both. The free tier gives you 3 boards at 12 shots each, with the storyboard PDF and public links included.

← All articles