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.

Date. Ask for one date, such as a date of birth or a start date. The crew member picks it from their phone's date picker, so there's no format to get wrong. Under Dates accepted you can leave it at Any date, or limit it to Today or earlier (a date of birth can't be next month) or Today or later (a start date can't be last week). The answer stays on the request; to save a date onto the contact record instead, use Fields with a date field.

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.

Sign PDF. Upload a PDF (a contract, a policy, a release) and ask each person to read and sign it. They open the PDF, tick that they've read it, type their name and draw a signature, and 1pm records the exact PDF they signed. Each of you can download a signed copy: the PDF with a signature page added. See Asking someone to sign a PDF.

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.

Fields. Ask for a value that fills one of your fields or a built-in contact detail, such as a licence number, a shirt size or a mobile number. The crew member gets the right input for the field's type: a text box, options to pick from, or a date, number or time picker. See "Saving an answer onto the contact" below.

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 Sign PDF request 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, Date, Terms, Sign PDF, 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.

Sensitive (Text, Date and Upload). For a tax file number, bank details or ID. The answer is stored encrypted, shown masked to your team, and only admins can view it in full, with every view recorded. See Keeping sensitive information private.

Show on run of show (Text, Choice and Date). Tick it on the request's row once it's added. Every answer then appears in the briefing at the top of the run of show / runsheet that crew open from their link, under Answers to requests, and updates when the answer changes. The answers also print on the run of show and BEO, yours and the crew's. Everyone with a crew link reads the briefing, and when several people answer, each answer shows who gave it, so keep it for answers the whole crew should see. It isn't offered on a sensitive request, and marking a request sensitive takes it off the run of show. Unticking Sensitive later doesn't put it back: tick Show on run of show again if you want it there.

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.

AI expiry date check (Upload with an expiry date). 1pm reads the expiry date on each uploaded file and compares it with the date the person entered. In Needs review, in the Review window, in the event's responses view and on the file on the person's contact, it shows AI check: matches the document, or AI read with the date it found, so you know which files to open. Until the file has been read it shows AI check pending, which updates when the result is in without a reload, and when no clear date could be read it shows AI could not read a date. Check it yourself. It reads PDFs and images, takes up to about 10 minutes after the upload, and never approves or rejects anything: that stays with you. When the date it read is different from the date entered, Approve is switched off for that file until you tick I checked the date, so a difference cannot be approved by accident. To stop it for a request, tick Don't use AI to check expiry date when you add the request, or No AI check on its row. Files for that request are then never sent to AI and show AI check not run.

Click Add. The request appears in the list above the form, and the crew member sees it on their live link straight away. When you are building a list, click Add and insert another instead: it saves the request and opens a blank form directly under it.

Choosing who is asked

Every request on a booking has an Asked of setting with three choices:

• Crew: everyone holding a link except the booking's client. Each crew member answers for themselves.
• Client: the booking's Client contact alone, such as a questionnaire about their day. Crew don't see it.
• Crew and client: everyone holding a link, the client included.

Whoever a request is asked of sees it on their link, counts it in their completion bar and is reminded about it when it's required. Nobody else sees it at all. So the client is never chased about a crew member's insurance certificate, and a crew member is never asked for the couple's first dance song.

A new request starts on Client when the booking has a Client contact and nobody else holds a link to it yet, which is the usual setup for a photographer or celebrant working with one couple. Otherwise it starts on Crew. You can change it before you click Add.

The row shows a Client or Crew and client badge, and the Asked of choice stays on the row so you can change it later. Answers already given are kept. If the booking has no Client contact, nobody sees the Client requests, and the panel shows a warning until you set one in Settings. On a portal everything is asked of the people on it, so the choice isn't offered there.

Saving an answer onto the contact

Pick Fields as the kind to ask a question whose answer goes into a field, then choose the field under Custom or linked field. The list has three groups:

• Custom fields are your own fields that keep each answer on its request only.
• + Save to contact are your own fields that also write the answer onto the crew member's contact record.
• Linked fields are the built-in contact details, such as mobile or website, and always write onto the contact.

Each crew member updates their own record, never anyone else's. You define your own fields under Fields in the sidebar.

For an Upload request, choose a field under Document type instead. The latest file each crew member sends becomes that field's current document, so a renewed certificate replaces the old one.

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.

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 above the timeline, titled "Requests all crew" by default (it uses your own crew wording). The booking's client sees "What we need from you" instead. To set one heading that everyone on an event sees, open the event's Settings, go to the Wording tab and edit Section heading. The Intro box under it adds a line of text, such as a deadline. 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.

For a date, they pick it from the date picker and tap Submit. The date shows beside the request, with a pencil to change it.

For a PDF to sign, they tap to open the PDF, then tick, type their name and sign, and tap Sign.

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.

One person can upload 30 files a day through their link, and your account can receive 500 files a day across everyone (100 a day on an account that isn't on a paid plan yet). Files that are uploaded and then deleted count too. Someone who reaches a limit is told on the page and can upload again the next day.

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.