How to Automate Dailies Delivery with Watchfolders and Presets

Start by deciding what a dropped file is supposed to become. The watchfolder is only the trigger. The real workflow lives in the preset and the folder structure around it. It also lives in the naming convention, in the error behavior, and in the record of what happened after the job finishes. One shoot day can produce several valid outputs from the same source media. Editorial may need edit-friendly proxies with synced audio and metadata. A director may need fast review files with burn-ins. A client may need a smaller, branded, watermarked version with limited access. Put all three targets behind one generic “transcode” folder and the system will make the wrong thing, fast. A good watchfolder setup makes the decision obvious before your team drops media. The person moving files shouldn't have to remember codec recipes, frame sizes, or watermark rules. They shouldn't be deciding where to upload the result at 1:00 a.m. They should only need to place the correct media package into the correct location.

Separate watchfolders can represent separate delivery intents.

Build the workflow around delivery targets

Dailies aren't just compressed copies of camera files. They're the daily bridge between set and editorial, production, and review. They arrive after your team has backed up, checked, and organized camera originals and production audio. Your automation should sit after data safety rather than ahead of it. The most reliable pattern is to create separate watched locations for each delivery intent. For example, a small production might use folders like this:

/Watchfolders
  /Editorial_Proxy
  /Director_Review
  /Client_Review
  /Audio_Only
  /Failed
  /Completed
  /Logs

Each watched folder maps to one preset or delivery recipe. The folder name should describe the output. “A001_Camera” is useful inside the media package. It can't tell the automation whether the result should be ProRes Proxy or DNxHD, H.264 review, or a WAV. A larger team may split by show, episode, shoot day, or unit:

/ShowName
  /S01E03
    /Day_014
      /Editorial_Proxy
      /Director_Review
      /Client_Review

That structure answers the questions that come up every morning. What did the system process? What failed? What was sent, and which version did editorial receive?

Choose presets by destination

Presets are where the workflow becomes specific. A preset should define the transcode settings and audio treatment, overlays, metadata output, plus the destination and any naming rules. Some systems separate transcoding presets from delivery presets, which is worth copying. The transcode preset says “make this kind of file.” The delivery preset says “put it here, name it this way, and send or register it with this destination.”

Delivery target	Typical output	Preset should prioritize	Common mistake to avoid
Editorial	ProRes Proxy, DNxHD, DNxHR, or another edit-friendly proxy	Source timecode, reel or clip metadata, synced audio, stable frame rate handling, relink-safe naming	Making a file that plays well but does not relink cleanly for conform
Director review	H.264, H.265, or platform-ready review file	Fast playback, timecode and clip burn-in, viewing LUT, simple delivery path	Overbuilding the file like an editorial proxy when speed matters more
Client review	Compressed review file with approved branding or watermark	Access control, watermarking, approved identifiers, limited metadata exposure	Exposing internal clip names, notes, or burn-ins that were meant only for production
Overview stringout	Combined day, scene, or selected-take sequence	Easy scanning, clear separators, useful burn-ins, small file size	Treating the stringout as an editorial source for cutting or conform
Audio or sync package	WAV, ALE, CSV, XML, or sidecar metadata	Channel mapping, sync references, clip IDs, NLE compatibility	Delivering picture files without the metadata or audio structure editorial needs

For dailies, the common preset families separate cleanly:

Editorial dailies: edit-friendly codec, consistent frame rate, source timecode, reel or clip metadata, synced production audio, and handles only if the editorial workflow expects them.
Director review: smaller file, fast playback, visible clip name and timecode burn-in, basic color transform or look, and delivery to a review platform or shared location.
Client review: compressed deliverable, watermark or branding if required, limited metadata exposure, and a destination controlled by production or post.
Quick overview strings: combined clips or scene/day compilations for fast scanning, not for editorial conform.
Audio replacement or sync packages: WAV, ALE, CSV, or sidecar metadata depending on the downstream system.

The takeaway is that “low-res” isn't a spec. Editorial low-res and client low-res are completely different files with different risk profiles. Editorial cares about relinking and timecode, audio channels, and metadata integrity. Client review cares about access and playback, approvals, and sometimes confidentiality. When you name presets, include the target and codec, the frame size and frame rate behavior, and the version. A name like Editorial_ProResProxy_1080p_SourceTC_v03 is ugly to read and impossible to misread. A name like Dailies_New will become a trap after the next prep day.

Decide whether the watchfolder is local, NAS, or cloud

The right location depends on where your team copies the media and who needs the result. A local watchfolder is simple and fast when a DIT, dailies technician, or assistant editor is sitting next to the encoding workstation. A NAS watchfolder makes more sense when several post team members or systems need access. A cloud watchfolder earns its place when remote ingest, automatic upload, or distributed review is part of the job. Each storage model trades something different:

Local storage: easiest to troubleshoot, lowest network dependency, but tied to one machine.
Shared NAS: good for a facility or editorial room, but requires permissions, mount stability, and enough throughput for simultaneous reads and writes.
Cloud storage: strong for remote teams and automatic distribution, but depends on upload speed, polling behavior, cloud costs, and transfer reliability.
Hybrid storage: common for productions that process locally, then upload completed outputs or metadata automatically.

Watchfolder automation runs in any of these models. Each one has a different failure mode. Local jobs fail when the workstation sleeps, runs out of disk, or loses access to a license. NAS jobs fail when permissions change, mounts disconnect, or another process moves files too soon. Cloud jobs fail when uploads are incomplete, credentials expire, or polling sees an object before it's fully available. Pick the location that matches the weakest part of your day. If set internet is unreliable, don't make cloud upload the first required action before editorial can start. If the assistant team is remote, don't strand completed dailies on a local machine with no transfer automation.

Make file arrival predictable

A watchfolder shouldn't process a file the instant its filename appears. Large media files can take minutes or hours to copy. If the automation grabs a growing file, you get corrupt outputs, partial transcodes, or strange failures that are hard to reproduce. A dependable watchfolder waits for stability before starting a job. It can scan at intervals and check whether file size has stopped changing. It can wait for a marker file. It can process a completed folder only after the transfer tool says the copy is finished.

A stable-file check keeps incomplete media out of the transcode queue.

Good arrival rules cover five behaviors:

Have the automation poll the folder at a predictable interval so it doesn't constantly hammer storage.
Ignore temporary, hidden, or partial transfer files.
Wait until file size and modified time remain stable for a set period.
Process folders as packages when audio, video, LUTs, and metadata must stay together.
Move or mark items once the automation has claimed them.

This is where simple automation becomes dependable enough for dailies. The bar is that the night assistant editor doesn't have to babysit every copy. If the workflow depends on sidecar files, camera reports, or production audio, ask whether a single media file is enough to trigger the job. The same question applies to ALEs, CDLs, and LUTs. The better trigger is often a completed shoot-day folder rather than an individual clip.

Keep original camera media out of the danger zone

Dailies automation shouldn't casually manipulate original camera files or original audio files. Studio guidance separates the responsibilities for backing up, archiving, and clearing camera cards, because the consequences are serious. Someone has to own archiving OCF and OAF. It may be the loader or the DIT, the dailies team, or post. If nobody knows who, automation makes the confusion worse. A safe pattern is to keep sources, work-in-progress, outputs, and transfer areas separate:

/Source_ReadOnly
/Watch_Incoming
/Processing
/Output
/Completed
/Failed
/Archive_Manifest

The automation reads from a controlled input and writes somewhere else. It shouldn't delete or overwrite source media. If your system needs to move files after processing, move the copied input package, not the only copy of the original.

Automation should read from protected media and write results elsewhere.

For camera card workflows, automation should begin after your team has verified offload and backup. That backup can be RAID or LTO, cloud object storage, or another approved plan, depending on the production. What counts is that nobody treats the watchfolder as the archive just because it contains media.

Design outputs for editorial relink

Editorial dailies have different requirements from review dailies. They have to survive the path from ingest to offline edit to turnover and conform. So the preset has to preserve the identifiers editorial will rely on later. For an editorial proxy preset, pay attention to these fields and behaviors:

Source timecode and duration.
Reel, tape, camera roll, or clip name strategy.
Filename consistency with camera originals or the agreed editorial convention.
Audio channel mapping, including mix tracks and isolated microphones.
Frame rate handling, especially for off-speed or mixed-rate material.
Color transform or viewing LUT, without baking decisions that should remain flexible.
Sidecar metadata such as ALE, CSV, EDL, XML, or project bins when required.

This is where editorial should have input during prep. Editors and assistant editors know what their NLE and turnover process need. A preset that looks fine in a review player is still a bad editorial file if it flattens the audio channels incorrectly or the reel name doesn't support conform. After the first test batch, open the files in the actual editorial system. Don't only play them in Finder or VLC, in Resolve, or in a browser. Confirm that the NLE sees the expected timecode and audio layout, the metadata, and the duration. Do that verification while you are still building presets, well before the end of the first shoot week.

Use burn-ins intentionally

Burn-ins are useful until they aren't. For director and production review, burn in the clip name and source timecode, the camera and scene/take, and the date. That saves a lot of back-and-forth. For client review, the same burn-in might expose information you don't want outside the core team. For editorial, burn-ins can help on picture, but they shouldn't replace real metadata. A practical burn-in strategy separates audiences:

Internal review: clip name, source timecode, camera roll, scene/take, shoot day, and look name if useful.
Director review: source timecode and clip or scene/take, usually with minimal clutter.
Client review: watermark, project branding, and only the identifiers production approves.
Editorial proxy: burn-in only if editorial wants it, with metadata preserved in the file or sidecar.

The preset should make those choices automatic. If someone is toggling burn-ins by hand for each batch, the wrong version will eventually go to the wrong audience.

Route completed jobs without relying on memory

The transcode is only half the delivery. Once the file exists, it has to land where the next person expects it. That might be a shared storage folder or an editorial NAS, a review platform, or a cloud bucket. It might also be a media asset manager or a transfer portal. For each preset, define the completed output route as part of the delivery recipe:

Editorial_Proxy -> /Editorial/Ingest/ShowName/Day_014
Director_Review -> /Review/Director/ShowName/Day_014
Client_Review -> /Review/Client/ShowName/Day_014

If your workflow includes uploads, the automation should record whether the upload completed, not just whether the local encode did. A successful transcode sitting in a local output folder isn't a successful delivery when the director is waiting in another city. For remote productions, watchfolder systems are often paired with automatic transfer tools. Your team drops media into a portal. The transfer tool copies it into cloud or NAS storage. The automation transcodes it. The system delivers it onward, with nobody downloading and re-uploading a batch by hand. That removes a lot of manual handoff, as long as every handoff point is logged clearly.

Treat failures as expected events

Every dailies system hits bad files and unsupported codecs, missing audio, and full disks. It hits disconnected storage, expired credentials, and human mistakes too. What separates a usable system from a stressful one is whether those failures are visible and recoverable. Useful failure categories include:

File still copying or never reached a stable state.
Unsupported, corrupt, or unexpectedly wrapped media.
Missing sidecar metadata, LUT, CDL, or production audio.
Preset mismatch, such as a codec the automation tool doesn't support.
Destination unavailable because of network, permissions, or credentials.
Insufficient local, NAS, or cloud storage.
Duplicate filename or already-processed package.
Application crash, worker timeout, or license issue.

Don't dump all failures into one mystery folder. Configure the automation to move failed jobs into a location that preserves the original package and writes a readable error report next to it. The assistant editor should be able to tell whether the fix is “retry after copy finishes,” “relink missing audio,” “use a different preset,” or “call engineering.” For retries, avoid automatic infinite loops. A corrupt file that retries forever can block the queue and hide newer work. Configure the system to retry a small number of times for transient issues, then quarantine the job and alert a human.

Log like someone will ask tomorrow

Dailies questions often arrive after everyone is tired: Did scene 27B go to editorial? Which preset made the client file? Was the director sent the version with the updated LUT? Did the upload finish before the notes call? Logging answers those questions without archaeology. A useful job log records the operational facts:

A useful job log gathers the operational facts in one record.

Source path and source filename.
File size, duration, codec, resolution, frame rate, and timecode start when available.
Preset name and preset version.
Output filename and destination path.
Job start time, finish time, and processing duration.
Worker machine or service that ran the job.
Transfer or upload status.
Error message and retry count if the job failed.
User or process that submitted the media, if known.

A CSV or JSON file, a database table, or a system dashboard can all work. Consistency is what counts. If the team can filter by shoot day and preset, by status, and by destination, most daily troubleshooting gets much faster. Preset version is especially important. If you change audio mapping or burn-in layout on day five, the log should show which files the system made before and after the change. Otherwise, you may not know which dailies your team needs to regenerate.

Keep humans in the loop where judgment matters

Automation is best at repeatable routing and encoding. It doesn't replace dailies supervision or color judgment, sync checks, or editorial communication. A watchfolder can detect new media and run a preset, upload the outputs, and write logs. It can't decide whether a LUT is creatively right, whether a take should be held back, or whether a metadata convention changed because editorial asked for it. A practical automated dailies workflow still has human review at the right points. The assistant editor or dailies technician should see enough status to catch missing clips and obvious sync problems, incorrect burn-ins, or failed uploads before those files become someone else’s problem. The best version of this workflow feels uneventful. Media shows up in a known place, and the system waits until it's safe to process. The correct preset runs for the intended audience. Outputs route to the right destination. Failures land in one place with readable reasons. Completed jobs are logged well enough that post can answer questions without digging through drives. So build the folders and presets before the first shoot day, then run one real day through them and read the log end to end. If that log tells you which preset made which file and whether it landed, the automation is ready to carry the schedule.

FAQ

Organize them by delivery target. A folder named for the intended output, such as Editorial_Proxy, Director_Review, or Client_Review, makes it clear which preset should run. Organizing only by camera roll or source type creates confusion, because the same camera media may need several different outputs.

A reliable watchfolder waits until files are stable before starting a job. Poll at intervals and check that file size and modified time have stopped changing. Ignore temporary transfer files. Require a marker file that confirms the copy is complete. For complex dailies packages, it is safer to trigger processing from a completed folder rather than from a single media file.

It should preserve source timecode and duration, reel or clip metadata, and filename conventions. It should also preserve audio channel mapping, frame rate behavior, and any required sidecar metadata such as ALE, CSV, XML, or bins. Test the output inside the actual editorial system to confirm that relinking, audio layout, metadata, and duration all behave as expected.

Review dailies are made for viewing, notes, and approvals. They use smaller compressed files, often with burn-ins, watermarks, or platform delivery. Editorial proxies are made for editing and later turnover. They need reliable timecode and metadata, audio mapping, and naming conventions that relink cleanly. A file that works well for review may be unusable for editorial.

Record the source path and filename, the media properties, and the preset name and version. Record the output filename and destination, the start and finish time and processing duration, and the worker machine. Then record upload status, retry count, and any error message. Preset version matters most, because it shows which files were created before and after changes to audio mapping, burn-ins, LUTs, or delivery settings.

Use a separate client review preset and destination, then restrict access at the folder, collection, or link level. Aspect supports view, download, comment, and edit controls, plus link expiry, so client dailies can be shared with granular permissions.