Plan deliverables
- Decide which outputs are actually needed at handoff: image, video, combined media, thumbnail, and any print-specific version.
- Keep output naming clear so operators can quickly identify what is guest-facing versus archival.
- Use Process recipes to lock branding, overlays, framing, and ratio choices before the first live capture.
- Keep the output list lean. Too many variants slow down review and increase wrong-action clicks at the station.
Match outputs to the delivery path
- QR and direct download should point to files that are light enough for phone delivery on event Wi-Fi.
- Email delivery should use the same branded files guests expect from QR, unless you intentionally send a different variant.
- Printing should have its own prepared source strategy (input, processed, both, or auto) so print quality is predictable.
- Portal delivery is best when links must stay valid after the station powers down.
Operator checklist before doors open
- Confirm one complete flow for each promised action: QR, email, print, and portal link when enabled.
- Confirm filenames and sorting make sense when multiple outputs are attached to the same capture.
- Confirm terms and custom fields only collect what the event actually needs.
QR sharing
- Use QR sharing when guests scan from the station and complete delivery on their own phone.
- Use it for single captures or multi-select batches from the Share screen.
Configuration points that matter
- Choose QR placement for operator clarity: overlay on media preview or hidden from inline cards.
- Tune QR size and overlay position so the code stays readable on your actual sharing display.
- Keep direct download enabled when guests should save files immediately after opening the share page.
- Enable "require email before QR" only when your event needs contact collection before phone handoff.
Live-operation checks
- Confirm Share is enabled and relay status is connected when using cloud QR mode.
- Scan from at least one Android and one iPhone device on the event network.
- Confirm both single-item and bulk QR flows if operators will share multiple captures together.
Offline QR sharing
- Offline QR mode bypasses cloud relay delivery and serves files from the local machine.
- The share modal shows two QR codes: one for joining Wi-Fi and one for opening the local download page.
- This mode is intended for venues with unstable internet or fully offline operations.
Setup requirements
- Configure a dedicated sharing hotspot and set the expected Wi-Fi SSID in Share Settings.
- Keep the sharing station and guest phones on that same local network segment.
- Test with real phones before doors open. Do not rely on desktop browser simulation for this mode.
Operational cautions
- If guests cannot join Wi-Fi, the download QR will still fail even if the code scans correctly.
- If the station sleeps, reboots, or changes network, retest both QR codes immediately.
- Use portal delivery instead when links must remain reachable after the local station is gone.
Printing
- Turn on printing in Share Settings, then enable the print action in the Share preset used at the station.
- Refresh the printer list and choose a preferred printer before the event starts.
- Set paper size and copy limits so operators cannot accidentally overload a printer line.
Choose print source strategy
- Input: fastest path from original files.
- Processed: uses branded outputs from recipes.
- Both or auto: useful when some captures have processed files and others do not.
- Enable fallback to input when processed files might not be ready in time.
Live print workflow checks
- Test single and bulk print flows from the actual Share station.
- Verify quantity prompts only if your team needs per-job copy overrides.
- Watch print job status (queued, printing, completed, failed) during early event traffic.
Email sharing
- Use email sharing when guests should receive a delivery link after operator confirmation.
- Registration and Final delivery each include Corporate (default) and Friendly templates with the shipped app. Corporate is assigned initially. The default event name is Xangle; a custom event title replaces it in emails. In Share Settings > Emails, select Registration or Final delivery, then choose from templates for that email type only. New and duplicated templates stay in the current type. The subject, reply-to, editor, and preview follow that selection. Save settings saves the edited templates and both assignments; edits are retained when switching between the two email types. Template customization remains optional.
- Use required terms and custom fields only where compliance or follow-up needs justify the extra steps.
Automatic email timing
- If the selected results are ready, the guest receives one Final delivery email after the normal upload checks.
- If processing is still pending when the guest submits an email, the guest receives Registration, followed by Final delivery when the results are ready.
- This works for local and cloud processing, including slow-lane Gaussian splats. Final rendering and output processing must finish before final delivery.
- No delivery timing setting is needed. The app follows each dataset's recorded processing plan, not the current settings for the next capture.
- QR email collection, sharing-tablet submissions, and direct email sharing use the same automatic timing. Generating a QR code alone does not send an email.
- For a bulk submission, one Registration email is sent if any selected dataset is still pending. One Final delivery follows after all selected datasets are ready.
- Final delivery keeps the existing selected-file and gallery behavior. It does not limit the selection to the output that finished last.
- Offline QR remains a local download flow. It does not provide email delivery without a working email transport.
Controls that affect delivery quality
- Enable multiple recipients only when operators are expected to send one capture to several contacts.
- Keep direct download available when email inbox access may be delayed on site.
- Verify SMTP sender configuration and test against real inbox providers before launch.
Queue operations
- Monitor queue state for sent, pending, uploading, and failed jobs.
- Use queue details to inspect dataset path, attached files, subject preview, and rendered email body.
- Retry failed items from queue actions after fixing config or connectivity issues.
- In Share Settings Logs, the email queue includes recipients Waiting for processing alongside upload waits and sent emails. Search by email or filter by status. Completed deliveries do not appear a second time.
- A failed processing task must be retried in the processing queue. Once it succeeds, automatic delivery resumes without another guest submission.
- Use the delivery retry action for failed email jobs after restoring connectivity or correcting the transport configuration.
- Cancel a delivery to stop its remaining queued emails. An email already being sent cannot be recalled.
Download email list
- Export from Share Settings Logs to download a CSV of email queue recipients.
- Each row includes recipient email, dataset folder, status, sent date, plus configured custom fields.
- The export reflects queue history and filters, so apply your date and state filters before exporting.
Why teams use it
- Post-event handoff to marketing or CRM systems.
- Delivery auditing for sent versus failed batches.
- Field-level analysis when custom form data is captured during sharing.
Good practice
- Export at least once during rehearsal to validate field mapping.
- Keep a final export snapshot at event close for reporting and recovery workflows.
Portal delivery
- Use portal delivery when links must remain active after the local sharing station is offline.
- Use it for events where guests often open media later, not only on-site.
Dependencies to verify
- Confirm internet reachability and relay connection from Share Status.
- Confirm the app has a valid login session. Invalid or expired sessions can block relay startup.
- Keep offline QR mode disabled when you need cloud relay behavior, because offline mode bypasses relay delivery.
Operational notes
- Run a full phone test from scan to final open link before guests arrive.
- Keep one operator check focused on relay and portal status after any network change.