Attaching a reference document to a request

Sometimes a request only makes sense once the crew member has seen the document that goes with it. A photography release they have to read before they tick "I agree". A contract to sign before they upload the signed copy. A floor plan to look at before they confirm their setup. A reference photo of the uniform before they pick a size. The thing you're asking for lands properly only when the supporting document is right there beside it.

A reference document is a single file or link you attach to a request, so the crew member reads it right where they respond. It's the planner handing something over as part of the ask, rather than only collecting something back.

How it differs from the rest of Requests

The Requests feature is built around collecting things from crew: a file, some text, a choice. A reference document points the other way. It's something you give the crew member to read first. The two sit together on the same request, your document on top and their response box below it.

It's also separate from the event's own file area. A reference document belongs to the request and shows only there. It never appears in the top-level file list for the event, so attaching a contract to one request doesn't clutter the event's general file area, and the same document isn't sitting in two places at once.

Attaching a document

Open the event in the planner and find the request you want to attach to in the Requests section.

Each request carries a small attach control (a paperclip icon labelled "Attach a document, link or YouTube video"). Click it and you get three options:

Upload a file. PDF, PNG, JPEG, or WebP, up to 10 MB. Add an optional label if you want the crew member to see a friendlier name than the raw filename.
Add from Files. Pick a document that already lives in your account's Files library. This is the one to reach for when the same document goes out on every event: the standard safety induction, the site rules, your public liability certificate. Nothing is copied, so updating the file in Files updates it on every request pointing at it, and you never upload the same PDF twice.
Add a link. Paste a URL to something you already host (Google Drive, Dropbox, a SharePoint file, a page on your own site, a YouTube video). You can give this a label too.

A Sign PDF request is the exception to the three options. Its document is the PDF each crew member signs, so it only takes a PDF you upload from your computer: a link or a file from your Files library is refused, because a library file can be changed later and that would change what people signed.

You can attach one reference document per request. That's deliberate. A request is a single ask, and one supporting document keeps it clear. If you need the crew member to read several things, either combine them into one PDF or split them across separate requests.

What the crew member sees

On their live link, the document shows inside the request as a button they can tap to open. Uploaded files open in a new tab; links go wherever the link points. It sits above the response box, so the natural reading order is: see the request, open the document, then respond.

Uploaded files are served through 1pm using the crew member's own secure link, so there's no separate login and nothing extra to share. Links open directly to wherever you pointed them, so make sure anything you paste is set to be viewable by the people you're sending it to.

Showing an image in place instead of behind a tap

When the document you attach is an image (PNG, JPEG, or WebP), a tap-to-open button is sometimes one step too many. If the picture is the instruction, the crew member should just see it. So for image uploads there's an extra option: Show image inline on every crew member's run of show.

You'll find it in two places, both on the planner side. When you first upload an image, a checkbox appears in the attach form. And once an image is attached, the same toggle sits next to it, with a small thumbnail so you can see exactly which picture you're switching. Tick it and the image renders directly on the crew member's card, in place, rather than as a button they open. The card shows a smaller web-sized copy so it loads quickly on a phone, and tapping the picture opens your original at full size.

The option only shows for images and YouTube links (see the next section). PDFs and other links always use the tap-to-open button, because they're meant to be opened and read in full rather than glanced at.

When to turn it on:

A "required PPE" photo above the box where crew confirm they have the gear.
A site-access map, dock diagram, or parking sketch so the load-in route is on screen, not a tap away.
A uniform or dress-code reference before crew pick a size or send a photo back.
An induction or safety graphic crew should take in at a glance.

When to leave it off: anything that needs reading in full. A multi-page contract, a Terms and Conditions document, or a detailed floor plan is easier to take in opened in its own tab, so the tap-to-open button serves those better. Inline is for the picture that does its job the instant it is seen.

Playing a YouTube video on the page

Onboarding and safety videos work best when crew can watch them without leaving their link. On a phone, a YouTube link usually opens the YouTube app, and the crew member then has to find their way back to finish the rest of their requests.

So when the link you add is a YouTube video, it plays right on the crew member's card instead. The card shows the video's thumbnail with a Play button. Pressing it plays the video in place, and the rest of their requests stay on screen underneath. An Open on YouTube link sits under the player, for a video whose owner doesn't allow it to be played on other sites.

This is on by default for a YouTube link. To switch it back to a plain link, untick Play the video on every crew member's run of show, instead of linking to YouTube next to the thumbnail on the planner side. In a request pack, the same choice is a checkbox under the link.

Any YouTube address works: a normal watch link, a youtu.be share link, a Shorts link, or a link with a start time (the video starts there). For a video you don't want public, set it to Unlisted on YouTube. Private videos can't be played outside YouTube.

Seeing who started the video

While the video is set to play on the page, the planner side lists under the toggle who has pressed Play and when they first did, for example "Sam Lee, 3 Oct, 2:14 pm". This tells you the video was started. It doesn't tell you how much of it was watched, and pressing Play doesn't complete the request. To have crew confirm they watched it to the end, make the request a choice or a task ("I have watched the safety video") so they tick it themselves. Replacing the link with a different video, or removing it, clears the list.

Removing or replacing a document

To take a document off a request, click the small remove control next to it on the planner side and confirm. To swap one for another, remove the current one and attach the new file or link. There's room for one at a time, so removing first is how you replace.

A document added from your Files library can be updated without touching the request at all. Open Files, click Replace file on its row and upload the new edition. Every request showing it, on every event, shows the new file straight away and keeps the title you gave it on the request. A PDF is replaced by a PDF and an image by an image, so a document shown inline stays a picture.

Knowing which version someone answered against

Every answer records the document it was given against: the file name and the date that file was uploaded. Press View on the request to see it under each answer, for example "Answered against induction.pdf, uploaded 3 Aug 2026".

If the document changes after someone has answered, because you replaced it in Files or uploaded a different file to the request, their answer is marked Answered before the document was replaced. That tells you who read the earlier version, so you can ask them to look again. Answers given after the change are not marked.

Someone who has the page open while you replace the document sees the new one within moments. If they answer from a page still showing the earlier document, the answer isn't taken: they are told the document was replaced, shown the new one, and asked to answer again.

Crew see the upload date under the document on their link, so both sides can tell which version is attached. A link has no upload date, so answers to a request with a link attached carry no document line.

If you delete the whole request, or delete the event, any reference document uploaded to it is cleaned up along with it. Uploaded reference files don't linger in storage once the request they belonged to is gone.

A document added from your Files library works the other way round, because it isn't the request's file to delete. Removing it from the request, deleting the request, or deleting the event leaves the file untouched in Files, ready for the next event. It also works in reverse: Files won't let you delete a document while a request still points at it, and tells you how many events are using it, so you detach it first.

When to use a reference document

Reach for it whenever the ask only makes sense alongside something the crew member needs to see:

A Terms and Conditions or safety document above an "I have read this" acknowledgement.
A contract or release form to read before uploading the signed copy.
A floor plan, run sheet, or stage diagram to look at before confirming a setup or a position.
A reference image (the uniform, the branding, the table styling) before they pick an option or send a photo back.
A briefing note that gives the question context the crew member wouldn't otherwise have.

For documents you're sharing with everyone that aren't tied to a specific question, the event Files area or an attachment on the run of show is the better home. Use a reference document when it belongs to one particular request and should be read right next to it.