Asking crew for documents and info

A run of show isn't the only thing a venue needs from crew. There's also the paperwork and the questions: a Public Liability certificate, a meal preference, a confirmation that they've read the brief, a phone number for their offsider.

The Requests feature in 1pm lets you ask each crew member for documents, answers, agreements, or a confirmation that they've done something, and collect everything in one place attached to the event.

This article covers the kinds of request you can add, how to set them up, what crew see on their live link, and how the response shows back to you.

Where to add a request

Open the event in the planner and expand the Requests panel, which sits with the other event-wide panels above the timeline. At the bottom of the panel there's a small form for adding a new request. You write each request once here, not separately for every crew member.

By default a request goes to every crew member on the event. Each person sees it on their own live link and submits their own answer or file, tracked independently, so the same Public Liability certificate request collects a separate document from each crew member who needs one. When you only want a subset to see something, wrap those requests in a named-crew conditional section: it reveals the requests inside it only to the crew you name. You can also gate a section on the answer to an earlier question, so (for example) the "what's your dietary requirement?" follow-up only appears to crew who said they're staying for the meal.

Each crew member's own row in the Crew accordion still carries a read-only Requests summary: exactly what that one person has been asked for on this event and what they've submitted, so you can check their status without leaving the run of show. The authoring all happens in the event-level Requests panel.

The kinds of request

Pick the kind when you add a new request. The rest of the form changes to match, so you only see the settings that apply to what you picked.

Upload. Ask the crew member to send you one or more files. PDF, PNG, JPEG, or WebP, up to 10 MB per file. You set a Min and Max number of files: Min 0 means optional, Min 1 or more means required, Max controls how many they can attach. Useful for licenses, certificates, riders, insurance documents, signed contracts, headshots, or supplier logos.

Text. Ask the crew member for a written answer. Toggle Multi-line on if you want them to have a paragraph-sized text area; leave it off for a single-line input. Useful for meal preferences, dietary requirements, an arrival ETA, a phone number, a song request, the URL of a portfolio, or a free-form question like "anything we need to know about your setup?".

Choice. Ask the crew member to pick from a list of options. Type the options into the Options box, one per line. Toggle Multi on to let them tick more than one option; leave it off to make it a single-pick. Useful for meal selections, role preferences, t-shirt sizes, time-slot preferences, or yes/no confirmations.

Enter just one option and it reads as a single tick-box acknowledgement, which is the quickest way to ask a crew member to confirm they've read something.

Terms. Present one of your saved terms templates and record the acceptance against the exact version accepted. You can require a typed name, a drawn signature, or both. Acceptance is append-only, so publishing a new version of your terms later never disturbs a signature already given.

Task. A checklist of things the crew member has to go and do, then confirm: complete the site induction, watch the safety video, walk the room. It collects confirmations rather than documents, and it holds the checklist inside itself, two levels deep: tasks, with steps under each. See "Reusing a setup" below for building one from a workflow.

Header. Not a request at all. A heading, with an optional description and attached document, for breaking a long list into readable blocks or giving crew something to read before they answer. It collects nothing.

Section. A conditional block. Everything inside it is hidden until its conditions are met. See the named-crew and answer gating described above.

You can mix kinds freely on the same event. A typical setup for a wedding photographer might be: an Upload request for their PLI certificate, a Text request for their backup contact number, a Choice request for meal preference, and a Terms block for your supplier agreement.

Setting up a request

After picking the Type, fill in the rest of the form:

Label. Required. Short description of what you're asking for. The crew member sees this as the title of the request on their live link. Keep it specific: "Public Liability Insurance Certificate" reads better than "Document".

Min and Max (Upload only). How many files they can or must submit. The defaults are Min 0 and Max 1, which means optional with at most one file. Set Min to 1 for a single required file. Set Max higher than 1 to collect multiple files (a contact sheet, several reference images, a multi-page rider).

Required. Available on every kind that collects something except Upload, so Text, Choice, Terms, Task, and a request saving to a contact field. When ticked, the crew member sees a "Required" badge on the request, and it counts toward their completion. Uploads have no Required box: they use Min instead, so Min 1 is what makes an upload compulsory.

Multi-line (Text only). Switches the crew member's input from a single-line box to a paragraph-sized textarea.

Multi (Choice only). Switches the crew member's view from radio buttons (pick one) to checkboxes (pick any number).

Expiry (Upload only). When ticked, the crew member has to enter an expiry date alongside each file they upload. The date shows next to the filename in your view, color-coded so docs expiring within 30 days warn and docs that have already expired show as errors. Useful for compliance documents that have to be current on the day of the event.

Click Add. The request appears in the list above the form, and the crew member sees it on their live link straight away.

Saving an answer onto the contact

Use "+ Save to contact" on a request to write its answer straight through to a field on that crew member's contact record, either a built-in field like mobile or website, or a custom field you've defined under Contacts, then Fields.

This is what stops an answer being buried in one event's history. Ask for a PLI certificate number once and it lives on the contact, ready to read next season without digging back through submissions. For uploads, the latest file becomes that field's current document, so a renewed certificate replaces the old one as the current value.

Point requests on several different events at the same field and they all keep it current.

Reusing a setup

There's no request-level template library, and an event template doesn't carry a request list: it pre-fills the new event's own fields, not its requests. Reuse comes from two places instead:

Custom fields. On a Choice request, tick "Save these options as a reusable custom field" and the option set is available to pick on future requests. Answers still stay on each request unless you also save them to the contact.

Workflows. Pick Task and use Add from a workflow: 1pm adds one task named after that workflow with its steps underneath. Apply two workflows to the same request and you get two tasks in it, or type a single one-off task instead.

The request stays one ask, so it's one line on the Requests dashboard however many steps sit inside it, while the crew member still gets per-step progress rather than one all-or-nothing tick. Tasks and steps tick independently, and items default to required so you untick the exceptions rather than ticking the rest.

Step text is read live from the workflow, so correcting a procedure once corrects it everywhere it's in use, and a description typed on the row overrides it for that event. What an item said is snapshotted when someone ticks it, so editing the procedure later can't rewrite what they already attested to.

Attaching something for crew to read

Any request can carry a reference document or link: upload a file, or paste a link to one you host elsewhere. Use it so crew can read the policy before they sign it, or see the setup photo before they confirm they've got what's needed.

Editing a request after it's added

Most fields on an added request are editable inline. Click into the label to rename it. Click into the description (the smaller line below the label) to add or change a longer instruction for the crew member. Adjust the Min, Max, or variant toggles directly on the row. Each change saves automatically.

You can also drag a request up or down using the handle on the left to reorder how the crew member sees the list.

Delete a request with the small X on the right. If the crew member has already uploaded files or submitted answers against it, those go too. Deleting is confirmed before it happens.

Archiving instead of deleting

Archiving takes a request off the live list without destroying anything. It stops being asked, it drops out of the panel's count and out of your default view, and the request plus every response already given is kept. Restore puts it back.

Archived requests stay hidden until you turn on the archived view, and each one carries an "Archived" badge so you can tell at a glance what's dormant rather than live.

Archive a question you've stopped asking. Delete one you should never have asked, and accept that it takes the responses with it.

What the crew member sees

On their live link, requests appear in a card titled "Requests" above the timeline. Each request shows the label, an icon indicating its type (cloud for upload, pencil for text, list for choice), and a Required or Optional badge.

For uploads, they tap to pick a file, optionally enter an expiry date if you've required one, and tap Upload. Submitted files show below the request as a list, with filename, size, and a delete button so they can fix a wrong file.

For text, they type into the input (or textarea for multi-line) and tap Submit. The submitted text shows below the request.

For choice, they tick the relevant option(s) and tap Submit. The selection shows below the request.

If you've set a Max higher than 1 for an upload, a progress badge appears: "1 of 2 files" or similar. Once they hit the Max, the form stops accepting new files until they delete one.

How responses come back to you

Every file or answer the crew member submits shows up in their request row on the planner side, with a delete button if you need to remove it. There's nothing to refresh: as soon as the crew member submits, the response appears in your planner view via the live update channel.

You can download submitted files directly from the planner view. The files are stored in 1pm; the crew member doesn't need to host them on Google Drive or Dropbox themselves.

Limits

An event can have up to 200 requests in total. That's more than enough for any normal event; the cap exists so a misconfigured form or a copy-paste accident can't create thousands of requests.

Each file upload is capped at 10 MB. For larger documents (high-res video, raw photo files), attach them as a link instead via the Attachments feature.

When you don't need this

Requests are designed for collecting structured information from crew. For ad-hoc messages or two-way conversation, they aren't the right tool yet (chat is on the roadmap). For documents the planner is providing to the crew, the Attachments feature is the right home. For things the whole crew needs to know, the briefing or per-crew notes are better.

Use Requests when you specifically need an answer or a file from a specific crew member, and you want all those answers collected in one place attached to the event.