# Playback stations and slideshows

Playable outputs are useful when the capture needs to be shown on-site, not only sent away. Sharing Server supports playback workflows for reveal screens, review stations, and looping displays.

## What it gives you

- Create a stronger payoff right after capture.
- Support on-site review without exposing raw folders.
- Turn finished outputs into screen-ready playback experiences.

## Why it matters

Some captures need a guest handoff. Others also need a visible result on a monitor, station, or slideshow screen. Treating playback as its own output class makes those setups easier to run.

## Read more in the docs

- [Player](/products/sharingserver/doc/media/player): Playable dataset behavior, slideshow modes, and player settings.

Playback stations and slideshows

# Features overview

Sharing Server turns incoming event media into share-ready, print-ready, and playback-ready outputs. It is built for photobooth teams, event activations, studio workflows, and technical integrations that need reliable handoff without constant manual sorting.

## Core workflow

- Watch incoming folders from booths, cameras, and export tools.
- Turn new arrivals into datasets automatically.
- Run recipes that build the output variants each job needs.
- Review the result in media pages, then hand it off by QR code, email, download, print, or local playback.

## Why teams use it

- One capture can branch into shareable, printable, and playable outcomes.
- Guest delivery can stay fast even when venue connectivity is weak.
- Operators keep assets, recipes, review, and delivery in one system.
- Private, operator-controlled handoff does not need to start from a public gallery model.

## Feature areas

- [Ingest and automation](/products/sharingserver/features/sharingserver/ingest-and-automation/overview): Watch incoming folders and keep operations moving with less manual babysitting.
- [Output routing and rendering](/products/sharingserver/features/sharingserver/output-routing-and-rendering/overview): Build different output classes from the same capture and automate branded processing.
- [Delivery and guest handoff](/products/sharingserver/features/sharingserver/delivery-and-guest-handoff/overview): Move files into QR code, email, download, print, and local sharing flows.
- [Review and playback](/products/sharingserver/features/sharingserver/review-and-playback/overview): Check results, browse datasets, and drive screen-ready playback experiences.

Overview

# Email, download, and print

Not every guest, client, or staff member wants the same handoff. Sharing Server can expose email, direct download, and print from one workflow so the final step matches the moment instead of forcing one universal option.

## What it gives you

- Adapt the last step to guest expectations and operator needs.
- Support digital delivery and print workflows from the same system.
- Reduce the need for side tools and manual file passing.

## Why it matters

The real advantage is flexibility under pressure. Some jobs need direct guest email. Others need a quick download or a print counter flow. Keeping those choices together makes the operation easier to run.

## Read more in the docs

- [Share](/products/sharingserver/doc/delivery/share): Card actions for QR code, email, download, and print.
- [Share Settings](/products/sharingserver/doc/delivery/share-settings): Form fields, templates, queue visibility, and printing behavior.

Email, download, and print

# Offline local sharing

Venue internet is not always reliable. Sharing Server can keep local handoff available when teams cannot depend on cloud relay as the main path.

## What it gives you

- Reduce delivery risk in temporary or unpredictable venues.
- Preserve the convenience of QR handoff in low-connectivity environments.
- Keep guest pickup moving without waiting on outside network conditions.

## What this changes operationally

When offline-friendly sharing is enabled, the guest path shifts toward local access instead of treating public internet relay as the only route. That makes the workflow more resilient for pop-ups, trade shows, and on-site activations.

## Read more in the docs

- [Share](/products/sharingserver/doc/delivery/share): Online and offline QR flows, including local handoff behavior.
- [Share Settings](/products/sharingserver/doc/delivery/share-settings): Offline QR settings, hotspot behavior, and delivery rules.

Offline local sharing

# Private-by-default delivery

Many teams want direct guest handoff without turning every event into a public gallery. Sharing Server is positioned around private, operator-controlled delivery rather than public exposure as the default story.

## What it gives you

- Keep the guest handoff focused on the participant.
- Make broader exposure an explicit operator choice instead of the baseline.
- Support privacy-aware workflows without losing delivery speed.

## Why it matters

For many activations, the strongest promise is not public visibility. It is respectful, dependable delivery that feels one-to-one and operator-controlled.

## Read more in the docs

- [Share](/products/sharingserver/doc/delivery/share): Delivery actions and guest-facing sharing behavior.
- [Share Settings](/products/sharingserver/doc/delivery/share-settings): Rules that shape how the handoff works.


Private-by-default delivery

# QR code sharing

QR handoff gives guests the fastest path from capture to their own device. In live event settings, that speed matters because every extra typing step can slow the line and increase operator involvement.

## What it gives you

- Reduce friction at the handoff moment.
- Keep guest flow moving in busy environments.
- Offer a delivery path that feels familiar and low effort.

## Why it matters

Fast delivery is not only a convenience feature. It changes how many people a team can move through an activation without letting the final handoff become a bottleneck.

## Read more in the docs

- [Share](/products/sharingserver/doc/delivery/share): QR code display modes, guest-facing share cards, and sharing actions.

QR code sharing

# Unattended operation

Sharing Server is most useful when it keeps moving after the setup work is done. Incoming media can be ingested, processed, reviewed, and prepared for delivery with much less manual babysitting between every capture.

## What it gives you

- Reduce operator load during high-volume runs.
- Keep delivery moving while staff focus on guests and production.
- Support multi-station installs without turning every handoff into manual file work.

## Practical point

Unattended does not mean uncontrolled. Teams still decide the event, recipes, share rules, and fallback behavior up front. The value is that the routine steps do not need constant operator attention.

## Read more in the docs

- [Watchfolder](/products/sharingserver/doc/watchfolder/overview): Automatic monitoring and ingest handoff.
- [Process](/products/sharingserver/doc/delivery/process): Auto-run recipes and render jobs.
- [Share Settings](/products/sharingserver/doc/delivery/share-settings): Delivery rules, queue monitoring, and offline behavior.

Unattended operation

# Watchfolder ingest

Watchfolder ingest lets Sharing Server meet capture systems where they already work. Instead of forcing operators to copy files manually or rebuild a booth around a new capture app, it watches the output folders they already rely on and turns new arrivals into datasets automatically.

## What it gives you

- Remove repetitive import and sorting work.
- Fit more easily into mixed booth, camera, and export-tool environments.
- Start processing and delivery sooner after a capture lands.

## Why it matters

Real-world event operations rarely use one perfectly uniform capture stack. Watchfolders make it practical to centralize delivery even when different stations, booths, or export tools are involved.

## Read more in the docs

- [Watchfolder](/products/sharingserver/doc/watchfolder/overview): Folder monitoring, ingest handoff, and automatic dataset creation.

Watchfolder ingest

# Branding assets and overlays

Branded delivery gets easier when overlays, intros, outros, LUTs, and soundtracks live in a reusable library instead of scattered event folders. Sharing Server keeps those building blocks ready for the recipes that need them.

## What it gives you

- Reuse approved branding materials across recurring jobs.
- Cut setup time before events and activations.
- Keep rendered outputs visually consistent across operators and stations.

## Why it matters

The pressure point is usually not whether branding is possible. It is whether teams can apply it quickly, consistently, and without rebuilding the same output chain for every booking.

## Read more in the docs

- [Assets](/products/sharingserver/doc/delivery/assets): Upload, preview, and manage reusable production files.
- [Process](/products/sharingserver/doc/delivery/process): Apply those assets inside recipe steps.

Branding assets and overlays

# Recipe-based processing

Recipes make output automation repeatable. Once you have a format that works for a campaign, venue, or client, you can save it and run it again instead of rebuilding the output chain for every new dataset.

## What it gives you

- Standardize output across operators and events.
- Auto-run the same render logic whenever new media lands.
- Produce more than one finished variant from the same capture.

## Why it matters

When delivery speed matters, the real win is not only rendering. It is knowing that the same capture will keep turning into the right outputs without operator hesitation.

## Read more in the docs

- [Process](/products/sharingserver/doc/delivery/process): Saved recipes, pipeline steps, queue state, and auto-run behavior.

Recipe-based processing

# Shareable, printable, and playable outputs

One file is rarely the right file for every job. A guest handoff, a print workflow, and a review screen often need different framing, resolution, or format decisions. Sharing Server treats those as separate outcomes instead of asking operators to compromise on one export.

## What it gives you

- Build outputs that match the real destination.
- Reduce operator guesswork under event pressure.
- Keep sharing, print, and playback workflows from fighting over the same file.

## Three practical output classes

- Shareable outputs are prepared for QR code, email, and download handoff.
- Printable outputs are prepared for print-first workflows.
- Playable outputs are prepared for review stations, reveal screens, and slideshows.

## Read more in the docs

- [Process](/products/sharingserver/doc/delivery/process): Output settings, active recipes, and multi-variant rendering.
- [Player](/products/sharingserver/doc/media/player): Playback behavior for playable datasets.

Shareable, printable, and playable outputs

# Media library

Review tools still matter in delivery-first workflows. Operators need a fast way to scan what just arrived, compare results, and clean up the gallery without dropping into the file system.

## What it gives you

- Review new datasets from one organized surface.
- Move faster on quality-control and housekeeping decisions.
- Keep bulk operations inside the app instead of scattered folders.

## Why it matters

When captures are arriving continuously, folder hunting slows everything down. A dedicated library makes it easier to decide what should be shared, archived, replayed, or cleaned up.

## Read more in the docs

- [Library](/products/sharingserver/doc/media/library): Gallery browsing, selection mode, and bulk actions.
- [Quickview](/products/sharingserver/doc/media/quickview): Single-dataset review, rating, and sharing.
- [Frames](/products/sharingserver/doc/media/frames): Snapshot-level inspection.

Xangle Sharing Server

Review and playback

Playback stations and slideshows

Playback stations and slideshows

What it gives you

Why it matters

Read more in the docs